| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
This contains configuration types that are shared between arti and
arti-rely.
|
| |
|
|
|
|
| |
This will allow this code to be shared between arti and arti-relay.
See: #2470
|
| | |
|
| |
|
|
| |
Removed unnecessary lint
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new method modifies a builder by replacing any unset values
that have a default with that default. We're using this method
so that we can re-serialize a builder into a `ConfigurationTree`
with all of its default values included.
In all cases, `b.apply_defaults()?; b.build()` should produce
the same output as `b.build()`.
The interesting parts of this commit are in tor_config::load
and tor_config::derive. The rest of this commit just adds
`apply_defaults` to other builders that _aren't_ made with
`derive_deftly(TorConfig)`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow these types to be shared by arti and arti-relay.
This does change these types from being behind the experimental-api
flag. I think this is okay, as tor-config is not a stable crate anyways,
but it's worth keeping in mind.
There is also an argument to be made for having two separate types, one
in arti and one in arti-relay, as we do for LoggingConfig. I think that
using a single type has benefits, and we should strive to eventually
merge the LoggingConfigs, for instance, and perhaps other types, but it
doesn't seem critical in either direction at the moment.
|
| | |
|
| |
|
|
| |
We'll use this in RPC to implement configuration changing.
|
| |
|
|
|
|
| |
This will be used by RPC. Probably. It might actually be a better
to re-serialize the configuration after parsing it, so that our
inspection functions can see default values.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| | |
|
| |
|
|
|
|
| |
I'm undecided whether we want to keep `resolve_alternative_specs`
around, but it seems possible/likely that we'll want it in the future,
so I think we can keep it.
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
This reverts commit c7c8eb5a03439ce31319389183e64cb0db539fc9.
|
| |
|
|
|
|
|
|
| |
This template is meant to replace most of our use of derive_builder
for configuration objects. Where possible and reasonable, it
delegates to existing macros, and automatically infers what special
patterns we use for individual types. In other cases, it uses
compile-time errors to inform the caller about pattern violations.
|
| |
|
|
|
| |
The derive-deftly TorConfig template will use these as appropriate
for the inputs to setter functions, based on field types.
|
| | |
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```text
error: implicitly cloning a `String` by calling `to_string` on its dereferenced type
--> crates/tor-config/src/lib.rs:109:32
|
109 | V::String(_, s) => s.to_string(),
| ^^^^^^^^^^^^^ help: consider using: `s.clone()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#implicit_clone
note: the lint level is defined here
--> crates/tor-config/src/lib.rs:20:9
|
20 | #![deny(clippy::implicit_clone)]
| ^^^^^^^^^^^^^^^^^^^^^^
```
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We're about to need this to define some of the configuration
for RPC listeners.
The provided map-builder type is much less voluminous in terms of
APIs added than the list-builder type: It just uses Deref* and sub_builder.
I think this simplicity may be a win.
I'll need to rethink how this type handles defaults in order to
implement connect points properly; I've left XXXXs for that issue.
|
| |
|
|
| |
We'll use this to implement defaults for maps in our configuration.
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
| |
Also updated other packages to get `CfgPath` directly from
`tor-config-path' instead of 'tor-config'.
|
| |
|
|
| |
This is a direct move of the `path` module from tor-config.
|
| |
|
|
|
|
| |
This moves the `assert_config_error` helper from the restricted
discovery config tests to a `testing` module in `tor-config` (I am about
to reuse it for the C Tor keystore config tests too).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
For the most part, this is just code motion.
The only change here is that `prepare` is no longer a method on
`FileWatcher`. This decouples `FileWatcher` from `ConfigurationSources`,
enabling us to use it to watch files and directories that aren't
configuration.
|
| |
|
|
|
| |
`BuilderExt` will soon be used in tor-hsservice too (for configuring the
mistrust settings of the client "restricted mode" authorization keys).
|
| |
|
|
|
|
|
|
|
|
|
| |
* Change `pub` to `export`
* Change the `=` in define to `:`
* Change `pub_template_semver_check` to `template_export_semver_check`
Right now, 0.12.1 supports both syntaxes. I have verified this branch
also compiles with
https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/merge_requests/402
ee171ffaf56d7dcb7d75584054921153fe19b222
|
| |
|
|
|
|
| |
* Bump in Cargo.toml
* Deal with `${Xmeta as ...}` incompatible change, by
always specifying an `as`, and changing `as tokens`.
|
| |
|
|
|
| |
We are about to need this in other crates (for generating the tests for
the `NotAutoValue` implementations).
|
| |
|
|
| |
This commit is automatically generated.
|
| |
|
|
|
| |
There are probably ways to make this a bit more elegant, but at
least the tests still pass.
|
| |
|
|
|
|
|
| |
This is a new feature in d-d 0.10.0.
Our currrent semver policy doesn't care about this, but let's not
encode that property in the tree and leave ourselves a booby-trap.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the combination of a number of separate commits, many of which
were generated by seddery, and then rebased and squashed.
Cargo.toml
perl -i~ -pe 's{^derive-adhoc}{derive-deftly = "0.10"}' crates/*/Cargo.toml
(not regenerated during rebase)
update Cargo.lock
`cargo fetch` without --locked
(regenerated during rebase)
seddery
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{^use derive_adhoc}{use derive_deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bdefine_derive_adhoc\b}{define_derive_deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bAdhoc\b}{Deftly}g if m{derive}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\#\[derive_adhoc\b}{#[derive_deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{use derive_adhoc}{use derive_deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc\b}{derive_deftly_adhoc} if m{use.*deftly}'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc!}{derive_deftly_adhoc!}'
(not regenerated during rebase)
Manually add `#[derive_deftly_adhoc]` where needed.
seddery
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\#\[adhoc\b}{#[deftly}g'
git-ls-files | grep '\.rs$' | xargs perl -i~ -pe 's{\bderive_adhoc_template}{derive_deftly_template}'
(not regenerated during rebase)
Manually fix up an import
Manually update some builder attrs
Manually fix up tor_rtmock::time_core
This was missed in my seddery, due to me rebasing the branch and not
redoing the seddery.
|
| |\
| |
| |
| |
| | |
Encapsulate usage of config-rs inside tor-config.
See merge request tpo/core/arti!2040
|
| | | |
|
| | |
| |
| |
| | |
These are another case of exposing the config crate.
|
| | |
| |
| |
| | |
This will let us replace Config with something better.
|
| | |
| |
| |
| |
| | |
Our macros use these exports, but we don't need everybody else to
be able to see them.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a better trickery! Now we don't need to derive the list of
field names at all.
The test case becomes much simpler too, and no longer needs to compare
field lists since we have only the serde field list.
|
| |
|
|
|
|
|
|
|
| |
This involves returning the field list in the
`FlattenableTesterSuccess`.
This leaves the names a little off; we'll update those at the end.
Export this - it's going to replace the hidden pub test function.
|