| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
This will help avoid the programmer making the mistake I made here:
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/852#note_2854029
|
| |
|
|
|
| |
We do want to test this with a non-Option type, but we are going to
have to wrap it up.
|
| |
|
|
|
|
|
| |
This lint exists for perf reasons, and this is rarely relevant in
tests.
Using double quoted str is generally cognitively less burdensome.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In answer to
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/632#note_2822107
I think this is subtle enough that it deserves a comment.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There are going to be some tasks (well, right away, one task) which
will want to go away when the sender is dropped.
The docs in postage are silent, but postage::watch::Sender does not
have a Drop impl so I don't think we can rely on the Receivers getting
None from their Stream impl.
So we're going to have the watch send Options, which are None only
when the sender is dropped.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to replace the AtomicBool for dormant mode with something that
can wake up tasks. postage::watch is the right shape.
But we want to be able to update it but suppress no-op updates.
(There is going to be a call site where no-op updates can occur.)
In the absence of a suitable upstream method as requested here
https://github.com/austinjones/postage-rs/issues/56
we introduce this facility via an extension trait.
|
| |
|
|
|
|
| |
Found these by disabling the nightly dbg macro special case. Now, we
have a mechanism for globally adding suppressions to tests, we can use
that instead.
|
| | |
|
| |
|
|
| |
These are warnings that we've decided it's okay to suppress elsewhere.
|
| | |
|
| |
|
|
| |
I think this is worse code, but it's not *significantly* worse.
|
| |
|
|
| |
I intend to reintroduce this in its own MR.
|
| | |
|
| |
|
|
| |
So we can change unwrap to expect, which makes this too long to repeat.
|
| |
|
|
| |
Apropos review.
|
| |
|
|
|
|
| |
When I added these tests, they didn't find any bugs in my own
implementation, but I did find a bug in futures::future::unfold.
See the in-code comment.
|
|
|
This is a general-purpose implementation of the ad-hoc approach
currently taken in (eg) crates/tor-proto/src/channel/reactor.rs,
with an API intended to defned against the more obvious mistakes.
This allows us to separate the two concerns: the channel reactor can
focus on handling channel cells and control messages and is over 2.5x
shorter.
The complexity of the manual sink implementation, and the machinery
needed to avoid having to suspend while holding an item, are dealt
with separately. That separate implemenation now has proper
documentation. (Tests are in the nest commit to avoid this one being
even more unwieldy.)
We use `extend` to define this as an extension trait. A competitor is
`ext` but in my personal projects I have found `extend` slightly
better.
|