| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| |
| |
| | |
We need to handle String, not just str, since some deserializers
have to handle escapes and generate new strings.
Found while writing tests; fixes #605.
|
| |/ |
|
| |\
| |
| |
| |
| | |
ChanMgr: Reorganize factory, builder, transport code.
See merge request tpo/core/arti!771
|
| | | |
|
| | |
| |
| |
| |
| | |
Since there is no longer a blanket implementation of ChannelFactory
for TransportHelper, we no longer need a separate type here.
|
| |/
|
|
| |
There is no actual code change here: just movement.
|
| |\
| |
| |
| |
| | |
Fix some rustdoc errors.
See merge request tpo/core/arti!770
|
| |/
|
|
|
|
| |
In addition to the usual "You named that method wrong!" errors, we
have a new rustdoc error that complains about bogus "HTML tags" that
are actually unquoted usage of types like `Result<Foo>`.
|
| |\
| |
| |
| |
| | |
chanmgr: Build and use chanmgr factory APIs
See merge request tpo/core/arti!769
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This will prepare for supporting multiple different ChannelFactory
implementations.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This lets us build channels using different TransportHelpers,
including the (new) default TransportHelper, which just uses the old
connect_to_one() code.
|
| | |
| |
| |
| | |
This will let us just have ChanMgr take a `dyn ChannelFactory`.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The traits that launch connections need to be async; the traits that
don't, shouldn't be async.
Additionally, we need a few more "Sync" annotations here for the
futures to work.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is an internal type (distinct from factory::ChannelFactory)
that we use to make the code in `tor_chanmgr::mgr` agnostic about
what a channel actually is, and how it is actually launched.
Therefore, I'm renaming it and giving better documentation in a
couple of places, to prevent confusion.
|
| | |
| |
| |
| |
| |
| | |
* Get `TransportId`
* Get the target address (of any type)
* Ask, "is this a direct connection"?
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Abolish maint/readme and use doc include
Closes #603
See merge request tpo/core/arti!768
|
| | |
| |
| |
| | |
This is not needed any more
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | |
| |
| |
| | |
Add some dummy definitions that support the example.
|
| | |
| |
| |
| |
| |
| | |
Add fn main wrappers to allow use of ?.
Add ,no-run to test cases that fail due to accessing the filesystem.
|
| | |
| |
| |
| | |
Add ,ignore to ignore three shell runes.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add ,ignore to ignore three examples that don't actually compile.
cargo readme would add these annotations to lib.rs, but the doc
include doesn't do stuff like that. pandoc seems to still render the
result just fine.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Rename Bridge to BridgeConfig
Closes #599
See merge request tpo/core/arti!767
|
| | | |
| | |
| | |
| | | |
Fixes #599
|
| | |/ |
|
| |\|
| |
| |
| |
| | |
Add bridges configuration section
See merge request tpo/core/arti!744
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This is what we'll use to parse the `bridges.bridges` config key.
|
| | |
| |
| |
| |
| | |
Callers could `use` it as `tor_guardmgr::config::BridgeParseError` but
it seems unecessary to force them to.
|
| | | |
|
| | |
| |
| |
| |
| | |
We're going to use this for the config item `bridges.enabled`,
but it seems general enough that it ought to go here.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We're going to want something that has the standard list builder
methods at the Rust API, but which has different serialisation.
Sadly the implementation is annoying, because macro_rules makes it
hard to parse a nice input syntax.
|
| | | |
|
| | | |
|