One of the tests run as part of `cargo test -p arti-client` fails
because the `pt-client` feature is not enabled by default:
```
failures:
---- src/config.rs - config::BridgesConfig (line 221) stdout ----
error[E0432]: unresolved import `arti_client::config::pt`
--> src/config.rs:225:26
|
7 | use arti_client::config::pt::ManagedTransportConfigBuilder;
| ^^ could not find `pt` in `config`
error[E0599]: no method named `bridges` found for mutable reference `&mut BridgesConfigBuilder` in the current scope
--> src/config.rs:233:19
|
15 | builder.bridges().bridges().push(bridge_1);
| ^^^^^^^ private field, not a method
error[E0599]: no function or associated item named `default` found for struct `BridgeConfigBuilder` in the current scope
--> src/config.rs:236:48
|
18 | let mut bridge2_builder = BridgeConfigBuilder::default();
| ^^^^^^^ function or associated item not found in `BridgeConfigBuilder`
error[E0599]: no method named `bridges` found for mutable reference `&mut BridgesConfigBuilder` in the current scope
--> src/config.rs:247:19
|
29 | builder.bridges().bridges().push(bridge2_builder);
| ^^^^^^^ private field, not a method
error[E0599]: no method named `transports` found for mutable reference `&mut BridgesConfigBuilder` in the current scope
--> src/config.rs:255:19
|
37 | builder.bridges().transports().push(transport);
| ^^^^^^^^^^ method not found in `&mut BridgesConfigBuilder`
error: aborting due to 5 previous errors
Some errors have detailed explanations: E0432, E0599.
For more information about an error, try `rustc --explain E0432`.
Couldn't compile the test.
failures:
src/config.rs - config::BridgesConfig (line 221)
test result: FAILED. 5 passed; 1 failed; 3 ignored; 0 measured; 0 filtered out; finished in 2.10s
```
This disables the `BridgesConfig` doc test if the `pt-client` feature is not enabled.
Closes#843
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
The key manager needs to be flexible enough to support loading keys from
one of several key stores. This is because when we add support for smart
cards, users will want to be able to store some keys on the smart card,
and others in one of the disk key stores (for example).
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This is the first draft of the key manager API.
I don't expect this to be the final version of the API, and I'm sure
there are plenty of improvements to be made. This is mostly a request
for comments.
Closes#834
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
Right now, this lets us say whether the method was unrecognized or
whether the parameter type was incorrect.
We'll use this to enforce correct method names later on.
(I have to add another `inventory` here, since the `typetag`
maintainer does not want to expose this functionality: see
https://github.com/dtolnay/typetag/issues/57#issuecomment-1506106290
)
Otherwise there is too much risk of accidentally adding in another
1<<12 when we meant to add a 1<<13.
(It would be neat to have an alternative to bitflags here that would
auto-number our bitflags for us.)
Previously the main loop received updates via a `mpsc::channel`, and
final responses via a `futures::unordered`. This could lead to
final responses being transmitted to the user before the updates
were all flushed.
Now all of the responses are sent to the main loop via the same channel,
and they can't get out-of-sequence.
Closes#817 and (IMO) simplifies the code a bit.