| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
| |
|
|
|
|
|
| |
The most frequent changes are:
- Rewording messages about poisoned locks
- Correcting some error types
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Check `unwrap_used` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#unwrap_used
This adds the following Clippy configuration to crates;
#![deny(clippy::unwrap_used)]
**Warning** while tests and compiler do not show any errors, the submitted
changes are very much a Work In Progress and mistakes may have been made. Check
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/67
Merge Request thread for more details.
|
| |
|
|
| |
Issue #74
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I've tried to remove some of possible panics, and improve the
documentation for when the others might occur.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
> Check `missing_panics_doc` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#missing_panics_doc
This adds the following Clippy configuration to crates;
#![deny(clippy::missing_panics_doc)]
And adds necessary doc-comments to methods that may panic.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
> Check `implicit_clone` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#implicit_clone
This adds, and addresses, the following Clippy configuration to crates;
#![deny(clippy::implicit_clone)]
And moves related line within `maint/add_warning.py` file. My intent is to
mitigate extra edits after merging, so please let me know if I need to do this
last bit differently.
|
| |/ /
| |
| |
| |
| | |
This way we can still use it even if we've removed too many
microdescriptors to make a real network.
|
| |/ |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
> Check `cast_lossless` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless
This adds the following Clippy configuration to crates;
#![deny(clippy::cast_lossless)]
And applies suggested Clippy and `cargo fmt` fixes.
|
| |/ |
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
Finishes #145.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our path-spec says that, if we don't have enough build-time data to
make a good estimate for our timeouts, we should periodically try
launching testing circuits just to see how long they take to build.
Here we implement that. The implementation is a bit wonky because
of how our crates are factored; see arti#161 for more info.
Closes #145.
Closes #57.
|
| | |
| |
| |
| | |
This won't work yet, since it needs directories and doesn't have them.
|
| | |
| |
| |
| |
| | |
We need the idea of launching a circuit for timeout testing, and
getting something that either exits someplace or exits noplace at all.
|
| | |
| |
| |
| |
| |
| | |
We'll want this for testing circuits and for RESOLVE requests.
Closes #155.
|
| |/ |
|
| |
|
|
|
|
| |
The timing is not ideal here; we'll want to refactor it later.
Closes #51
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Since these futures rely on the current time when they decide when
to expire, we don't want them looking at the current time from
inside the call to runtime.spawn or after that call. Instead we'd
like them to look immediately on construction.
This approach is based on a comment from janimo on #149. It doesn't
fix #149, though.
|
| |
|
|
|
| |
There's more to do here: we never actually store the data we get
here, and we won't work at all when somebody else has the lock.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This patch makes path configuration and request timing options get
exposed up to the tor-client level. I'm trying `derive_build` here
so we can eventually get consistent across all our builders.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
Relays on the same IPv4 /16 or IPv6 /32 are treated as being in the same
family.
|
| |/ |
|
| |
|
|
| |
Signed-off-by: dagger <[email protected]>
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The good news is that this tests the succeeding and failing cases,
and even managed to expose an off-by-one error in our hop counting.
The bad news is that these tests have shown even more ways in which
our wait_for code is unreliable, and forced me to slow it down even
harder.
|