| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
These errors aren't ignored anymore.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Explain the code for the #952 fix.
See merge request tpo/core/arti!1391
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Let's explain what Trinity did in its fix for #952, so that we know
why this code is here the next time we find it.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This launders the closure so that clippy's
clippy::redundant_closure_call can't see it.
We can't have a local #[allow] because it would be on an expression,
which isn't allowed on stable.
This avoids having to use more clumsy idioms at call sites.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This fixes a needless_vec lint on nightly.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes #920
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There are a number of places where we generate random Durations
in a range which starts at zero.
These call sites currently (i) have to write out Duration::ZERO
or equivalent, and (ii) would have to use gen_range_checked and expect
the result, even though it can be statically proven to be OK.
To make this slightly smoother, provide `GenRangeInfallible` and
`gen_range_infallible`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Ideally we would be allowed to use vanilla gen_range() here, but there
doesn't seem to be a way to allow a specific clippy-forbidden method
using #[allow] and we probably don't want to make a blanket allow.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
In each of these, it is locally obvious that the range is nonempty.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
delay_bounds's implementation ensures the postcondition, so the
potential p[anic in next_delay_msec cannot happen.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We will use this in many places instead of gen_range.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
keymgr: Use Box<dyn EncodableKey> instead of Box<dyn Any>.
Closes #937
See merge request tpo/core/arti!1398
|
| | | | | | | |
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1337#note_2917701
This will make it harder to accidentally return the wrong value from
`Keystore::get` (the returned value is now at least guaranteed to
implement `EncodableKey`).
Closes #937
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Overhaul send_control_message
See merge request tpo/core/arti!1367
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The feature name is wrong now.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
I think this name is fine.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
handle_msg is going to want this in a moment.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If the circuit is just being used by us (which is likely, if we're
using this API) then the only reactor we're blocking is our own.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Now, after you call start_conversation_last_hop, you can send more
messages if you like.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're going to want to do almost-the-same thing but without installing
a new handler.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is just a placeholder for now, but it'll be a thing you can send
more messages with.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Was send_control_message.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're going to let people start a conversation and either expect to
receive first, or send messages ad-hoc later.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Was UninstallHandler. We are going to talk more about conversations
and less about handlers (although, the fact of there being a handler
will still be visible).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Nothing else wants this and having it pub(super) is confusing.
|
| |\| | | | |
| |/ / / /
|/| | | |
| | | | |
| | | | | |
tor-hsclient: Mock traits: Work around an async boobytrap
See merge request tpo/core/arti!1365
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix new "useless_vec" warning from clippy +nightly
See merge request tpo/core/arti!1395
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Explanation at
https://rust-lang.github.io/rust-clippy/master/index.html#/useless_vec
This is the non-tests subset of the same-named commmit in !1388,
(recreated by hand by me, and then checked against that commit;
I stole the commit message from Nick's.)
This should be uncontroversial I think.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Clippy nightly now detects when you're calling into_iter() and
passing the result into something that accepts an
`impl IntoIterator`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
See here for documentation on the lint:
https://rust-lang.github.io/rust-clippy/master/index.html#/diverging_sub_expression
The issue here, from what I can tell, is that the lint triggers
whenever you use a diverging expression as a function body within an
|
| |/ / / /
| | | |
| | | |
| | | | |
We're doing this deliberately, I believe.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
RFC: tor-rtmock: Use derive-adhoc for composite runtimes
See merge request tpo/core/arti!1381
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It is no longer experimental, but still not rated for security-sensitive
usage per <https://blog.torproject.org/arti_116_released/>.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Originally they didn't check err.kind(), since err.kind() can never
increase their severity. We lost that behavior with !1386, and we
became dependent on it with arti!1383. Since they both merged at
the same time, CI broke.
This patch restores their original behavior.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
arti: Build with HS client support by default
Closes #948
See merge request tpo/core/arti!1382
|