Important refactoring happened recently which broke the
"experimental-api" feature.
Fixes are quite simple.
Signed-off-by: David Goulet <dgoulet@torproject.org>
These lints force us to declare our exported enums and
exhaustive-looking structs as non-exhaustive (so that we can add to
them in the future without breaking our API) or to explicitly
disable the warning for a given enum/struct (to say that we _intend_
for additions to be a breaking change).
Since we moved to a non-async mutex(*), we no longer need to worry that
this function might need to suspend.
(*) This is _not_ safe in general, but it's okay in this case, since
we never suspend while holding that mutex: see shared_ref.rs.
This function sits behind an `experimental-api` feature so that we
don't need to worry about exposing the entire surface of DirMgr to
our API consumers.
This and the other recent patches are based on work from dgoulet.
This is consistent with the other pieces of tor-proto, which do not
handle timeouts on their own. It also lets us remove tor-rtcompat
as a dependency from tor-proto, and simplify some of the test cases
to use async_test.
This commit unindents a lot of test code; use git's "-b" flag to
read the parts that matter.
Now other crates don't need any 'ifdef tokio' code, since there
are wrappers that implement 'futures' right.
Technically, the 'futures' traits are in some ways less good than
the tokio ones, but we need a consistent API if we want to support
WASM someday and keep support for async_std. I'd rather hold out
hope for a future version of futures::io working like tokio than to
fix ourselves into the tokioverse forever.
Previously we'd flush after every write. Now we only flush when the
reader has nothing more to tell us. This way we can be sure that we're
sending out the data as soon as we can, without leaving any cells
partially filled unnecessarily.
These new (internal so far) APIs correspond more closely to what
we'll need for AsyncRead and AsyncWrite.
We also make write methods take a mutable reference to self, since
that seems to be (closer to) what the AsyncRead/AsyncWrite code
expects.
This is fairly ugly and I think I'll need to mess around with the
feature configuration a while until we get something that's pleasant
to develop with. This still seems like a good idea, though, since
we _will_ need to be executor-agnostic in the end, or we'll have no
way to handle wasm or embedded environments.
Later down the road, we'll probably want to use futures::Executor or
futures::Spawn more than having global entry points in
tor_rtcompat. That would probably make our feature story simpler.
Tokio is the default now, since tokio seems to be more heavily used
for performance-critical stuff.
This patch breaks tests; the next one will fix them, albeit
questionably.
This affects the cache_dir and the as-yet-unused state_dir. It uses
the shellexpand and directories crates so that the default values
can be constant strings that use variables to refer to the right
default locations.
Nick Mathewson
David Goulet