| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
proto: Move celltypes out of client
See merge request tpo/core/arti!3355
|
| | |/ / /
| | | |
| | | |
| | | |
| | | | |
Some of these are relay-specific, so it makes more sense to pull this
into a top-level module.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
proto: Stop using tunnel IDs in relay reactor.
See merge request tpo/core/arti!3353
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Using a tunnel ID here doesn't make much sense right now, because we
don't yet support exit-side conflux (and when we will, it's unclear
whether the concept of "tunnel" will be applicable, especially if we
refactor things such that multi-path circuits are handled without a
ConfluxSet-like type like we have for clients).
This change forces us to stop using the client-specific
`unwrap_or_shutdown` (because this macro expects `self` to have a tunnel
ID), but IMO that is okay.
|
| |/ / /
| | |
| | |
| | |
| | | |
We can optimize for the general (N <= 3) case, and avoid a heap
allocation.
|
| | | |
| | |
| | |
| | |
| | | |
We don't really need this and it raises questions, for example
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3337#note_3271871
|
| | | |
| | |
| | |
| | |
| | | |
Previously we needed this separate type because Ios8601TimeSp is
FromStr which prevented a correct ItemArgumentParseable impl.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We're going to want to change some now-public fields to use these types.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1.85.1 rejects this, because it doesn't extend the lifetime of the
`format_args!`. 1.90 is fine with it.
I want to keep `format!` not `String::new()` so that it's easy to
change back. That means a clippy allow. Getting that to apply to the
code inside the derive is tricky, so I've enabled it for the whole
module. (IMO this clippy lint is pretty annoying anyway.)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We'll want to general way to find the error problem column.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Provide facilities in ArgumnetStream for determining the column, and
add the field to all the error types up to and including ErrorProblem.
The value still needs to be propagated to ParseError, and printed there.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This will allow us to (1) move field name handling out of the argument
parser method, and also (2) add columns more easily.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We're about to have some functions return ArgumentError and some
ErrorProblem. We don't want to provide a conversion directly between
these types, so instead introduce a new type that will be convertible
to either.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-proto: allow comparison chain
See merge request tpo/core/arti!3342
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It was decided that the comparison chain was actually preferrable for
readability. So instead, we're just `allow`ing it until it stops being
a problem.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There was a comparison chain in
`tor_proto::util::poll_all::test::ResolveAfter::poll` which was causing
a clippy warning. The lint in question, `clippy::comparison_chain`, was
a `clippy::style` lint in 1.85.1 and got moved to `clippy::pedantic` in
1.87.0 (see [rust-clippy!14219]).
Since some of us (like me) develop on MSRV, I'm fixing this lint now.
Gabi didn't have any strong opinions on whether I did it like this or
with an `allow` attribute, so I decided this was better since it means
we don't have to come back later just to remove the `allow`.
It should be noted that using a match like this can sometimes be a
performance regression (see [rust-clippy#5354] and [rust-clippy!6390]).
I would expect in this case the effect will be very little, if any, but
if tests in `tor_proto::util::poll_all::test` start taking much longer
and having an impact on CI or something, this could be why.
[rust-clippy!14219]: https://github.com/rust-lang/rust-clippy/pull/14219
[rust-clippy#5354]: https://github.com/rust-lang/rust-clippy/issues/5354
[rust-clippy!6390]: https://github.com/rust-lang/rust-clippy/pull/6390
Signed-off-by: hashcatHitman <[email protected]>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-netdoc: impl NormalItemArgument for Ipv4Addr and SocketAddr
See merge request tpo/core/arti!3343
|
| | |/ / /
| | | |
| | | |
| | | | |
AFAICT we don't have variant parsings for these things.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
And remove one that we didn't need.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We'll add a `TorRelay` back in a following commit.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
