Currently, the `maint/coverage` script does not inform about the
dependencies required for generating the HTML output, those are, the
Python packages `bs4` and `lxml`.
This commit fixes that, by updating the help section accordingly.
This commit removes a list we provide for the supported grcov formats.
In my opinion, this is a practice of bad software engineering, as we would then
have to maintain this list by ourselves.
Therefore, this commit removes this list from the `maint/with_coverage` script
and replaces it with a references to the accompanying grcov command.
Instead of having 2 version of `StreamTarget::close` (a blocking one and
a nonblocking one), we can just return the `oneshot::Receiver` for
receiving the reactor's response and let the caller of
`StreamTarget::close` decide whether to block.
This allows us to reduce some code duplication in the `IncomingStream`
implementation.
This will allow us to proceed if
* the default config file locations can't be established
(eg due to failure of the `directories` crate), but
* configuration files are explicitly specified,
so the defaults wouldn't be used
Improves the error mesage in #989 somewhat.
Before:
target/debug/arti: error: Can't construct project directories to resolve a path element
After:
target/debug/arti: error: identify default config file locations: Can't construct project directories to resolve a path element
The two enums essentially serve the same purpose, so we don't
need both of them.
This also addresses the TODO that says we should return an error if
`accept_data` is called for a RESOLVE stream.
This is a follow-up from !1451.
This commit solves a `TODO HSS` introduced when `DataCmdChecker` got an
additional constructor (`new_connected`) for creating "pre-connected"
streams. See f6745d31 for more details.
Propagating the error means will cause the reactor to shut down (there's
not much the control message sender can do about it, so there's no point
in sending it the error).
As a result, by the time the `reject` future resolves, the stream has
been removed from the reactor's stream map and the corresponding END
cell has been sent.
Fixes#998.
`ClientCirc::allow_stream_requests` is now `async` and waits until the
`AwaitIncomingStream` control message is processed by the reactor.
This guarantees that by the time the `allow_stream_requests` future
resolves, the reactor is ready to process BEGIN/BEGIN_DIR/RESOLVE cells.
Previously, the client tasks from allow_stream_requests tests had to
sleep before sending the BEGIN cell to give the reactor time to process
the `AwaitIncomingStream` control message (which tells the reactor to
expect incoming BEGIN/BEGIN_DIR/RESOLVE cells on the circuit).
Fixes#994
The implementation here is perhaps excessively simple: we put
a `oneshot::Sender` in the `Reactor` object, and a
`Shared<oneshot::Receiver>` in the circuit or channel. When
the reactor is dropped, any copy of the `Shared<Receiver>` will
yield `Err(Cancelled)`.
I'm marking these methods as experimental because I'm not sure I've
thought of all the implications here, and we might want to change
things around.
Down the road, these methods might want to yield a `Result<>`
indicating why the reactor was shut down.
This feature was inspired by a request from Saksham Mittal, and a
felt need while working on !1472.
This will enable hidden services to send `RENDEZVOUS1` messages to the
`N`th hop of the circuit rather than the `N + 1`th virtual one (which
can only used after the client and service have completed the
introduction handshake).
This also deprecates `start_conversation_last_hop`.
Closes#959
`HopNum` will be used in `ClientCirc`'s public API when we refactor
`ClientCirc::start_conversation_last_hop` to use the provided hop rather
than always using the last one.
Emil Engler
Ian Jackson
Ian Jackson
Gabriela Moldovan
Nick Mathewson