| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
There's a complaint (seen in a CI build log) about over-eager iterator
item cloning. This is a perf complaint and not very relevant in tests.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #939
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This lets us provide less information in our logs: in particular, it
lets us avoid logging with microsecond precision.
Closes #551.
|
| |
|
|
|
| |
This moves `storage.keystore_dir` to a separate `declare_exceptions`
block and explains why we have this exception.
|
| |
|
|
|
|
| |
Let's remove this until we figure out how the config should behave when
the `keymgr` feature is disabled (should it accept or reject
`keystore_dir = true`?)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It's used for declarations only, and they should all be here.
|
| |
|
|
|
|
| |
As per discussion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1320#note_2916689
and IRC followup.
|
| |
|
|
|
|
|
| |
I think these should go in `[circuit_timing]`. That section already
has some retry parameters, so is not strictly *timing*.
This is not honoured yet.
|
| |
|
|
|
|
|
| |
We put this in `[address_filter]`.
The interaction with the corresponding stream preference is a bit
complicated. We must turn the stream pref into a `BoolOrAuto`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was super confusing and fragile. Amongst the problems:
* Information about exceptional config keys was spread across a
number of places, manipulated in ad-hoc ways (conditional Vec
appends, etc).
* As a consequence, each exceptional table has confusing and unclear
semantics.
* It doesn't deal well with the way that cargo sometimes enables
features for dependency crates even if arti itself wouldn't demand
them; this can lead to sub-crates supporting config keys when the
tests in arti don't expect them to, causing spurious test failures.
Fix this:
* Introduce a new, systematic, way of writing information about
configuration keys that need some kind of special handling.
* Use this new approach in *both* sets of "thorough" config tests.
* Be more relaxed about deprecated keys. We don't want to tightly
couple this to absence in the supported file, I think.
* Understand more clearly the concept of keys of which we don't know,
in the current build config, whether the code is expected to
accept them.
I have tested this locally with:
for p in '-p arti' '--workspace'; do for f in '--no-default-features --features=tokio,native-tls' '--all-features' ''; do nailing-cargo test $p $f; done; done
|
| |
|
|
|
|
| |
We *do* have a thing that works like this.
It's fragile and confusing and that's what I'm about to fix.
|
| |
|
|
|
| |
Bring the exciting tests together, and move some more normal tests out
of the middle.
|
| |
|
|
|
|
|
| |
If all the fields vanish, this generates a warning with
cargo clippy --locked --offline --workspace --all-targets
Fix that.
|
| |
|
|
|
|
|
|
|
| |
Now there's a module in `arti` that runs the loop for an RPC
listener. The part of the old `listener` module that made
the framed connections is now part of the `Session` object.
There is now yet another a temporary location for the pipe; we
should pick something better. At least now it's configurable.
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now parse the `bridges.enabled` BoolOrAuto, and the
`bridges.bridges` list.
The `bridges.bridges` list is Vec<()> in the builder, and Vec<Void> in
the built config. Ie, it is simply a count, and vanishes in the built
config.
But this count triggers us to try to call build(), to try to parse
bridges, and to try to set and honour the enablement boolean.
The result is that the type system now ensures that if bridges are
disabled, but specified (either by listing them in the config, or
writing `enabled=true`), we inevitably try to insist that we have a
non-empty Vec<Void>, which is of course impossible.
There will be a test case too for those who think this too abstract a
way to guarantee this property :-).
|
| |
|
|
|
| |
Maybe this will want to be in tor-error or something but put it here
for now.
|
| |
|
|
|
|
|
|
| |
This test will start to fail if you compile without bridge support,
because we'll start rejecting the test configurations with bridges
specified.
We'll add a proper test for this later.
|
| |
|
|
|
| |
It looks like, despite a few false starts, they've got this warning
right; there weren't any false positives.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/823#note_2854365
|
| |
|
|
|
|
| |
If there are subkeys which are covered by also expected_missing
superkeys, delete them, since we expect the superkey to be missing, so
the subkey won't show up.
|
| | |
|
| |
|
|
| |
Giving this a name will allow us to refer to it docs in a moment.
|
| |
|
|
|
| |
This allow is also present in the standard lint block at the start of
the test inline module.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This demonstrates that:
* !bridge-client: uncommenting nondefault bridge config generates
urecognized config key warnings (but the config is still accepted)(
* bridge-client, !pt-client: uncommenting nondefault bridges generates
error due to attempting to use a PT. If that's filtered out,
everything is fine.
* pt-client: Everything is good (as before).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Introduce filter_examples and resolve_examples helpers,
which will become more complex in a moment.
* Move the API test into a { } block to minimise subsequent diff.
It's going to become conditional.
* In subsequent comparisons, use the parsed version, since
the API built one might not exist.
No overall functional change.
|
| | |
|
| | |
|
| | |
|
| | |
|
