| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
We're going to separate RelayFlag from RelayFlags.
We could continue to provide a bunch of constant values for
RelayFlags, for each individual type, but that would involve an ad-hoc
derive, and would still be a bit of an unusual API.
Instead, we're going to make ``RelayFlag` a normal enum.
In this commit, we change everyone to refer to it by its singular
name. Hopefully separating out this bulk change makes both this, and
the core commit, easier to review.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Many call sites pass one flag. We're going to have a type-level
distinction between a single flag and a set. But that's annoying at
many of the call sites which want to specify a fixed single flag.
Note that `set_flags` doesn't only set flags. It replaces them.
|
| | |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Implement this on DocRelayFlags instead, since that's what it returns.
And change the name to from_item_consensus to highlight its semantic
restriction. (It's not generic over the implied flags, so it can only
do one thing.)
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
maint: Upgrade num-bigint-dig to 0.8.6
Closes #2110
See merge request tpo/core/arti!3475
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This appears to resolve the warning:
> warning: the following packages contain code that will be rejected by a future version of Rust: num-bigint-dig v0.8.4
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
tor-netdoc: Overhaul RelayFlags, and provide for conditionally retaining unknown info
See merge request tpo/core/arti!3454
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Some of the new formatting is a bit unfortunate. Ah well.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3454#note_3288967
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
There are currently no options.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're going to add options arguments, effectively, to the parsing
entrypoints. To avoid a proliferation of entrypoints (eg,
parse_multiple_with_options), encapsulate the run-time input values in
this structure.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
I would do `#[deprecated]` but empirically that has no effect...
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will have space for unknown flags.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is the minimal change to provide sanity.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Currently the only exposed API for parsing RelayFlags is the FromStr
impl which is very strange. I'm going to remove it. But there should
be a replacement.
So improve RelayFlagsParser:
* Derive Debug and Clone.
* Replace the `&'static str` error.
* Make sure unknown `IMPLIED | IMPLICIT` is detected at compile time.
* Make it pub.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Provide a per-variety alias and use it for parsing; no longer impl
ItemValueParseable for RelayFlags.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Which bits are implied/omitted depends on the document!
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The API is a bit clumsy, but we're mostly going to use it internally.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add underscores so that the spec keywords and the flag constants
correspond (according to `paste`'s case-changing rules).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* Document the bizarre FromStr impl. That isn't in my way, so I
don't intend to fix it. So I've documented it instead.
* Mention the naming discrepancy.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
We're going to do a lot more with this and it's less confusing to have
it all together.
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | | |
proto: Split CircHop into inbound and outbound components
See merge request tpo/core/arti!3470
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The relay reactor needs the cc state to be shared between the inbound
and outbound components (i.e. the forward and backward reactors), so we
need to put the cc state behind a mutex.
There will never be any contention on this mutex in the client impl,
because the client reactor doesn't split the `CircHop` into
`CircHopInbound` and `CircHopOutbound`.
In the future, we should work on trying to reduce the number of locks in
the `CircHop` states.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
These will be soon used by relays too.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The Inbound/Outbound CircHop states will be used in the relay reactor,
so it's helpful to move some of the `CircHop` impl there.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will be used by relays too, once we modify it to make the `HopNum`
optional.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Unlike the client reactor, the relay reactor uses these components in
separate tasks. Splitting `CircHop` this way enables us to reuse its
parts instead of duplicating them in the relay impl.
Eventually, I'd like us to rewrite the client reactor to follow a
similar pattern.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|