| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
Create and use an ErrorHint type to report how to fix a problem.
Closes #579 and #578
See merge request tpo/core/arti!994
|
| | | |
|
| | |
| |
| |
| | |
Split off for ease of review and possible rebase.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
With safe logging disabled, print the error too.
With safe logging enabled, do not print the message or the error.
|
| |/ |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This brings the draft configuration mechanisms in tor-ptmgr in line with
the config in other crates, using builders. It also plumbs the config
type through into the main `arti-client` config, and adds some example
lines to `arti-example-config.toml`.
|
| | |
|
| |
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
Upgrade to clap 3
Closes #616
See merge request tpo/core/arti!830
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also replace Arg::takes_value with Arg::action to configure flags
that don't take parameters vs options that do.
This makes it easy to upgrade to clap 4.
Tested deprecations with:
cargo check --workspace --all-features --features clap/deprecated
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This removes the last cargo audit override (for the unmaintained
ansi_term).
Don't mark options as required when they have default values:
see <https://github.com/clap-rs/clap/pull/3793>.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Apparently cargo fmt doesn't like these, which my perl rune didn't
delete.
This commit is precisely the result of `cargo fmt`.
|
| |
|
|
|
|
|
|
| |
The feature we want is `#[doc = include_str!("README.md")]`, which is
stable since 1.54 and our MSRV is now 1.56.
This commit is precisely the result of the following Perl rune:
perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
