Rust 1.52 just came out, and there are new clippy lints to deal
with:
* It spots more cases when we could use Option::map
* It spots more cases when we could use Iterator::flatten
* When we build a struct instance, it wants us to list the fields
in the same order that the struct declares them.
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).
Previously we read too much data from our input, and then used the
unused portion as an initial state of a buffer for handling
subsequent data. Yuck! Instead we can just use an AsyncBufRead and
only read the parts we want.
This code takes some pains to never read too much data: I'd rather
just "read until the first CRLF" or have some kind of pushback
mechanism. But for now it's probably fine.
The big idea of this revision is to separate the code that knows
about doing downloads from the code that decides what to download.
Later, we can make a similar change for database access. With these
changes together, we can make our code much more testable, and
eventually enable more download types in parallel.
This will let us use these types both as client and server-side
implementations.
Making this change required me to change the download code to take
requests by reference. (Sorry, David)
Having "no descriptors" mean "all of them" is kind of an accident
waiting to happen, and had wrong behavior for partial_docs_ok() and
max_response_len().
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.
Nick Mathewson
David Goulet
Kushal Das