| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Canonicalise the `logging.journald` setting in the validated
configuration. Now it will never be `Some("")`, even if that is what
was written in the config file.
This allows us to write `journald = ""` in the example configuration.
(Without the canonicalisation the default builder produces `None` and
the example would produce `Some("")`, which are semantically identical
but fail the test.)
See https://gitlab.torproject.org/tpo/core/arti/-/issues/488 for some
background.
|
| | |/
| |
| |
| |
| | |
These violate our rule that *built* structs ought not to be desr.
But this is just in a test.
|
| |\ \
| | |
| | |
| | |
| | | |
Add a few coverage-based tests to tor-config.
See merge request tpo/core/arti!540
|
| | | |
| | |
| | |
| | | |
There's nothing major here, but it does fill in a few gaps.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Revert "Remove dbg!()s in tor-config"
See merge request tpo/core/arti!552
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This was done because Nightly Rust complained about these, despite
them all being in tests. That is now fixed upstream:
https://github.com/rust-lang/rust-clippy/issues/8758
https://github.com/rust-lang/rust-clippy/pull/8838
This reverts commit 9d26a91886990b08dc5b6033c290d417489c61fc.
|
| |/ /
| |
| |
| |
| |
| | |
Utilize cargo-sort: https://github.com/DevinR528/cargo-sort
Signed-off-by: Orhun Parmaksız <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Break TorClientConfig out of ArtiConfig and warn on unknown config keys
Closes #459 and #417
See merge request tpo/core/arti!529
|
| | |
| |
| |
| | |
We can have mem::take, hooray.
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807331
|
| | |
| |
| |
| |
| |
| |
| | |
This was a slip.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807330
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This makes the function a tiny bit clearer.
|
| | |
| |
| |
| |
| | |
This is not a doc comment because we don't want it to be public: it
must refer to private fields, etc.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Not available in our MSRV.
|
| | | |
|
| | |
| |
| |
| | |
I think this is a leftover from a previous version of this expression.
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807070
|
| | |
| |
| |
| |
| | |
Instead of the wrong "prefix_len". As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807068
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807078
This is in fact much clearer than the Option.
|
| | |
| |
| |
| | |
Split into its own commit to avoid churn in the rename commits.
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807077
|
| | |
| |
| |
| |
| | |
As per review comments
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807076
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This turns out to need quite a complicated algorithm.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
ConfigurationSources: Allow config files to be world-readable.
Closes #475
See merge request tpo/core/arti!528
|
| | |
| |
| |
| | |
Fixes #475.
|
| |/
|
|
|
| |
This is an approximately minimal revision to get Builder in place;
subsequent commits will clean up the API.
|
| | |
|
| |
|
|
| |
This should satisfy our CI and turn it green again.
|
| |\
| |
| |
| |
| | |
Abolish arti-config, replacing with tombstone crate
See merge request tpo/core/arti!508
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|