The compiler can apparently tell that we aren't generating compile
errors! Also that we're not yet using a feature provided here.
(New lint in currently Nightly.)
This commit was made by reverting the previous commit, then
re-running the script I used to generate it. In theory there should
be no semantic changes: only changes due to improved formatting from
cargo edit.
I followed the following procedure to make these changes:
* I used maint/changed_crates to find out which crates had changed
since 0.3.0.
* I used grep and maint/list_crates to sort those crates in
topological (dependency) order.
* I looked through semver_status to find which crates were listed as
having semver-relevant changes (new APIs and breaking changes).
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no changes. For those crates, I incremented their patch-level
version _without_ changing the version that other crates depend on.
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no obvious breaking changes.
* I treated all crates that depend on `arti` and/or `arti-client` as
having breaking changes.
* I identified crates that depend on crates that have changed, even
if they have not changed themselves, and identified them as having
a non-breaking change.
* For all of the crates, I used `cargo set-version -p $CRATE --bump
$STATUS` (where `STATUS` is `patch` or `minor`) to update the
versions, and the depended-upon versions.
These crates had only clippy fixes that do not affect their
behavior:
tor-bytes
tor-cell
tor-events
tor-linkspec
tor-netdir
tor-socksproto
This crate only had the cargo-husky dependency removed, which
does not affect compatibility:
tor-llcrypto
Since these changes have no compatibility effects, it is not
necessary to bump the versions of these crates which other crates
depend on.
It turns out that the `toml` crate can't handle OsString, since
`toml` doesn't support serialize_newtype_variant, and the `serde`
crate tries to serialize OsString using that method.
In this commit we document that limitation, and test that we can at
least round-trip through json.
Found by inspecting test coverage.
Now that the relevant functions now report changed/not-changed
status via a boolean out-parameter (see !527), there's no reason to
have a separate NoChanged error case.
Closes#484.
This gets rid of `#[serde(flatten)]` which prevents serde_ignored (and
other kinds of introspection) from working properly.
The price is now that the toplevel has to deal with two configuration
objects.
The Resolvable trait is overkill right now, but is going to do More
Things in a moment. In particular, we need the impl on tuples, so
that the whole config can be processed in one go.
We are going to need this for some generic code which is going to
appear shortly. Having it produced by impl_standard_builder seems
best. But that does mean being able to disable it, so extra stuff in
the macro. Nothing uses this trait yet.
ConfigResolveError is not used now either, but will be in a moment.
We are going to reorganise ArtiConfig to not contain a
TorClientConfig. This test case's calls to bld.tor() will all need to
change. Do this in advance to make that future commit more readable.
I don't understand why this isn't tripping all the time. Maybe
because this is in a macro. Anyway, I am going to add a new
invocation of this macro from within a test where, empirically, it
trips.
This change requires a little refactoring of TorClientBuilder: now,
instead of enabling or disabling mistrust, it enables or disables
the decision to _override_ the mistrust in the config.
We support all of the following (in TOML notation):
```
user = "rose" # by name
user = 413 # by ID
user = false # no user
user = ":current" # A 'special' user.
user = { name: "rose" }
user = { id: 413 }
user = { special: ":none" }
user = { special: ":current" }
```
Previously in !511 I had introduced a bug where, if there was an
error more serious than "no change", that error would keep us from
noticing that we had no change, and we'd loop until the safety
counter ran out. Then we'd panic.
This commit fixes the bug by reintroducing the `changed` boolean --
this time as an outparam for the add_from_* methods.
Fixes#482.
this change adds unit tests for the public methods of StreamPrefs. although
these are mostly "setter" style functions, the tests confirm the basic
expectations and operation.
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.
We no longer have separate return paths for recoverable and fatal
errors; instead, they are merged, and distinguished based on
recovery actions.
Since it is now possible for download() to give an error that should
_not_ destroy the previous state, it takes `&mut Box<dyn DirState>`.
This change unfortunately means that we can no longer call `state =
state.advance()`, but instead have to do some mem::swap junk with
poisoned values. Any better solution would be a good thing.
Additionally, the reset() and advance() methods can no longer fail.
There is still a separate return path for reset-triggering errors;
I'm about to fix that.
Previously, we did this in `advance()`, but that wasn't so great: it
meant that we could fail in the advance() code, whereas the calls to
`advance()` treated errors as fatal.
This treats failed verification as a blocking error that requires a
reset.
Fixes one aspect of #439.
Previously DocSource would tell you whether the document was from
a local store or a cache server, but it wouldn't tell you _which_
server it came from.
This change required adding DocSource as an argument to
DirState::add_from_download.
Generally, change the paths that mention the crate name to go via a
module-level "use".
This involves adding tor-config as a direct dependency for a few
crates.
This crate no longer has any reason to exist. All its remaining
functionality is generic enough to go into tor-config.
In this commit, we move the contents of lib.rs into a new file in
tor-config. It contains:
* Code motion
* The minimal "mod" and "use" changes
* The minimal doc comment
* A new a compat alias for ConfigurationSources.
The compat alias is there because various crates currently speak of
arti_config::ConfigurationSources and it is most convenient to fix
them up after the type is available in tor_config.
This is a benchmarking tool, and fs-mistrust doesn't like the
permissions in our CI. The env var ARTI_FS_DISABLE_PERMISSION_CHECKS
is (of course) specific to arti. Maybe it should be honoured here,
or this should be done via the config files.
But disabling this is fine for now.
Test the Deserialize impl of every config struct.
This detects bugs like the one fixed in !502.
The macro now becomes more complex because it needs to take options.
Right now this tt-munching option parser is overkill, but this
leave space for further options in the future.
This was anomalous, in that it contains &'static str, rather than a
proper nested error (eg a config::ConfigError, maybe).
But in fact it tursn out it is now not constructed. The last
construction site was removed a long time ago in
Use derive_builder for Authority and FallbackDir.
I have Plans for this macro. In particular:
* I have a wip branch which tests that the Builder can be
deserialised from an empty config (ie, that config reading
of a config with a blank section for this item works).
* I think we should autogenerate $Config::builder(),
and promote that, rather than $ConfigBuilder::default().
This macro could do that.
This macro is kind of derive-y. Also it has a test in it, and failing
to call it could allow bugs to exist, as well as missing bits of API.
Putting it next to the structs makes it easy to see that it's actually
been called.
We expect that a user may copy this file and uses it as a starting
point for their own configuration.
When they do that, we don't want them to freeze the default config in
time. Instead, we can expect them to uncomment settings they wish to
change. Then when they upgrade arti, *other* settings will get the
new defaults, which I think is right.
This is redundant, because the defaults have to be supplied by the
config builders (usually via builder default attributes).
That this is actually done and correct is tested by the
`default_config()` test case in arti/src/cfg.rs.
Ian Jackson
Nick Mathewson
Ian Jackson
trinity-1686a
Alex Xu (Hello71)
eta
Jim Newsome
michael mccune
Dimitris Apostolou