| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| |
|
|
| |
This is part of an implementation for proposal 368.
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Update `StreamPollSet` to require that its streams implement
`PeekableStream`, and to not do its own buffering of values read from
the stream.
This avoids an extra layer of buffering for streams that already
buffer a value, and makes the interior state a little simpler and more
robust.
It does have a downside of making the API a little less convenient,
since the caller must do its own `poll_peek` call if it wants a
reference to the item.
* Update `StreamMap` to implement `PeekableStream` for
`OpenStreamEntStream`, as it must to satisfy the updated
`StreamPollSet` API. We have to somewhat constrain the
`poll_ready_streams_iter` API to no longer return both a reference to
the stream and the message. I don't see a way to return both
while satisfying the borrow checker. Luckily we don't really need both
anymore.
* Update the Circuit reactor to handle the updated
`StreamMap::poll_ready_streams_iter` API.
|
| |
|
|
|
| |
This was required to be the same type as `S::Item`. We can just use
`S::Item` directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bullied by clippy. I'm on the fence whether this is actually an
improvement, or whether I should add an exception.
```
error: consider using `Option<T>` instead of `Option<Option<T>>` or a custom enum if you need to distinguish all 3 cases
--> crates/tor-proto/src/util/stream_poll_set.rs:106:56
|
106 | pub fn remove(&mut self, key: &K) -> Option<(K, P, Option<Option<V>>, S)> {
| ^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#option_option
= note: `-D clippy::option-option` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::option_option)]`
```
|
| |
|
|
|
|
| |
This simplifies the bookkeeping a bit, and clears a path towards
updating the Streams in our StreamPollSet to directly respect flow
control.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of wrapping `FuturesUnordered`, which doesn't support efficient
access to its internal futures, keep the futures themselves in our own
HashMap, and use a custom Waker to be notified which futures are ready
to be polled.
*Almost* a pure refactor in this step - the implementation now requires
that keys are `Send + Sync + 'static` so that we can put them inside an
`Arc` and send them over a channel.
|
| |
|
