| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |/
|
|
|
|
|
|
|
| |
We're doing this because the type now holds "all the mutable state
in a ChanMgr", not just the map.
This is a pure renaming; no documentation has been updated.
Part of #606.
|
| | |
|
| |
|
|
| |
renamings are now #623. Code movement can happen later.
|
| |
|
|
| |
These are newly present on 1.65. We can address them later.
|
| | |
|
| |
|
|
|
|
|
|
| |
0.99.[012] have a bug https://github.com/JelteF/derive_more/issues/114
which makes the Deref derive for bridgedesc::StateGuard not work
and therefore breaks minimal-versions CI.
It seems simpler to require the newer version everywhere.
|
| |\
| |
| |
| |
| | |
Allow GuardMgr to expose bridges as guards (part 1)
See merge request tpo/core/arti!785
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now it contains either an `OwnedChanTarget` or an `OwnedCircTarget`,
which will let `GuardMgr` return bridges that can be used to make
circuits.
As part of this change, it was necessary to revise some
address-modification functions that applied to filters and
`OwnedChanTarget`. Now they do the smart thing, and remove only the
address that are in the `ChanMethod`. This means that the addresses
from HasAddrs are still accurate about which addresses the relay
"has".
|
| |/
|
|
|
| |
If pt-client is disabled, there are in fact no tests, so the module is
empty. But we would always want `use super::*` here.
|
| |
|
|
| |
This causes CI problems, and is entirely my fault.
|
| |
|
|
|
|
|
| |
This is a compromise between C tor (never escapes = signs) and the
spec (calls for escaping all = signs). In C tor there is no way to
actually construct a key with an = sign in it, so this difference
should be undetectable.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is mostly a matter of encoding parameters in the format used
for socks authentication.
|
| |
|
|
|
|
|
| |
This code is _not_ conditional, since we want to support running
with a proxy even if we don't support pluggable transports.
We may eventually want to refactor this into a new create.
|
| | |
|
| |
|
|
|
| |
This can happen in weird corner cases, so it's probably best to
report it rather than having an "internal error."
|
| |
|
|
|
|
|
| |
Now, instead of duplicate checks in various cases, we simply go
through the loop one last time.
This allows us to simplify some of our other logic around here.
|
| |
|
|
|
| |
This function had grown huge and hard to reason about. Before I
make it even worse, let's split it up.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Thanks to our previous changes, we no longer need this type, or the
methods that access it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary so that we can look up channels (open and pending)
by all of the Ids that we know about them.
The operations needed here are pretty complex: to get them right,
I've replaced most of the accessors on the inner `ChannelMap` with a
function that holds the lock while another `FnOnce` is called. This
still gets us the invariant that we can't accidentally await while
holding the lock on the `ChannelMap`.
I've removed the tests for the accessors that are no longer there.
There are some subtleties here. Now that we have more than one kind
of Id, it's possible to have a partial match. I've tried to explain
all these cases in the comments.
}
|
| |
|
|
|
| |
This will let us migrate from `HashMap<Ed25519Identity, Entry>` to
`ByRelayIds<Entry>`.
|
| |
|
|
|
|
| |
This is mostly a testing only change for now too, but soon I'll use
it to deal with the fact that we need to know the IDs to actually
build a channel at all.
|
| |
|
|
|
| |
This is mostly a testing-only change for now, but soon I'll use it
so we can have IdMap for our channel map.
|
| |
|
|
|
|
|
|
| |
The `ByRelayIds` type doesn't have a type equivalent to
`hash_map::Entry`, since it's a set type rather than a map
type. Therefore, the only plausible way to do entry mutation will
be to remove the old entry and insert a new one. And so, we no
longer need a "poisoned" state.
|
| | |
|
| |
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
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 lint exists for perf reasons, and this is rarely relevant in
tests.
Using double quoted str is generally cognitively less burdensome.
|
| |
|
|
|
|
|
| |
Now each `ChanTarget` has at most one `ChannelMethod`, and only
`Direct` `ChannelMethods` can have multiple addresses.
Closes #600.
|
| | |
|
| |
|
|
| |
All the other users of HasAddrs are correct.
|
| |
|
|
| |
These are now builders.
|
| | |
|
| | |
|