| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| |
| |
| | |
Set socket buffer sizes (`SO_SNDBUF` and `SO_RCVBUF`) for proxy sockets
Closes #2500
See merge request tpo/core/arti!3957
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds the trait type `ListenOptions` to `NetStreamProvider` and adds
this `ListenOptions` as an argument to `NetStreamProvider::listen()`.
You probably want to look at the changes in tor-rtcompat first, then the
rest of this commit is updating the various places we use
`NetStreamProvider`.
|
| |/
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| | |
|
| |
|
|
| |
Typos found with codespell
|
| |
|
|
|
|
|
|
| |
futures 0.3.32 has deprecated UnboundedReceiver::try_next() in favor of
UnboundedReceiver::try_recv(), but try_recv() was only introduced in
0.3.32, so using it would cause our minimal versions checks to fail
(rightfully so, because our code wouldn't build with futures 0.3.x for x
< 32).
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| | |
|
| | |
|
| |
|
|
|
| |
These are as yet unimplemented; there's a stub type
for the providers (nativetls) that won't actually have them.
|
| | |
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| | |
|
| |
|
|
|
|
|
| |
I want to use this as an example in a talk.
Add a blank line that makes it more readable, and generate only one
impl block with many methods.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Run cargo fix --edition
2. Selectively revert the "if let"->"match" changes.
These changes are meant to protect us from the lifetime changes
for "if let" bindings in Rust 2024.
But we're not actually relying on the old lifetime rules
anywhere, and the match syntax here is quite ugly.
3. Automatically revert `$pat:expr_2021` to `$pat:expr`.
(We don't actually want to restrict the expression syntax
that our macros accept).
Done with
`git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'`
4. Run cargo fmt.
|
| |
|
|
| |
These only serve as a compile-time check.
|
| |
|
|
| |
See #2060.
|
| |
|
|
| |
Fixes: #2033
|
| |
|
|
|
|
|
| |
The `IoError::other` function is an easier way to say
`IoError::new(IoErrorKind::Other, ...)`. It's been around since
1.74, but clippy started warning about the more verbose version in
1.87.
|
| |
|
|
|
| |
Option::replace has been around since 1.31,
but the clippy warning is new.
|
| |
|
|
|
| |
This doesn't seem to happen with my local compiler. Anyway, suppress
it. I don't think we want to split up this function.
|
| |
|
|
|
| |
This gets rid of a clippy complaint about subthread_block_on_future
being too complicated.
|
| | |
|
| |
|
|
| |
The future no longer needs to be `Send + 'static`.
|
| | |
|
| |
|
|
|
|
|
|
| |
This test demonstrates that the intended use pattern compiles and
works.
It couldn't exist until now because we couldn't conveniently make a
`Send + 'static` future out of `rx.next()`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we put the future into the data structure, had the exeuctor
poll it there, and only woke up the subthread when the future was
ready.
Now, instead, we put a new TaskFutureInfo variant into the data
structure, and the executor context switches to the subthread every
time. Then we poll the future on the subthread.
Moving the future into the data structure meant we had to do use a
proxy future to store the return value. Now that's not needed any
more.
Now the future doesn't need to be Send + 'static.
Fixes #1933.
|
| |
|
|
|
|
| |
Eliminate the data_ variable and instead use a block scope.
This seems a bit nicer, and will align slightly better with
forthcoming changes.
|
| | |
|
| | |
|
| |
|
|
| |
We're going to introduce a new call site for this.
|
| |
|
|
| |
Be clearer that `fut` is only `None` during the main loop.
|
| |
|
|
|
|
| |
SubthreadFuture was a type in some early version of this branch, that
it's not in-tree now. subthread_spawn returns impl Future and the
concrete type is a channel receiver.
|
| |
|
|
|
|
| |
We change `NoUnixAddressSupport` to `NoAfUnixSocketSupport` because it
doesn't make much sense to talk about support for the addresses
separately from support for the sockets.
|
| | |
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2843#note_3169975
|
| | |
|
| |
|
|
| |
Let's use Tokio terminology here.
|
| |
|
|
| |
This is the TODO we are fixing with this MR.
|
| |
|
|
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2810#note_3167975
Also allow ourselves the option of changing this in the future.
|
| | |
|
| |
|
|
|
| |
This will let us call _inner from blocking_io, with a different
precondition. No functional change.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is going to become a hazard. Let's be explicit.
This means using educe to derive the Default for Data.
We also need to update our educe dependency to 0.4.22, since that's
when Default(expression= "...") started working correctly.
|
| |
|
|
|
|
|
|
| |
execute_until_first_stall is now simply a wrapper which does some
logging. It will do a bit more in a moment.
Giving the inner function a more obvious name is helpful, since the
executor main loop is a thing one is often looking for.
|