| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| |
| |
| | |
Split OTLP exporter into separate crate.
Closes #2611
See merge request tpo/core/arti!4297
|
| | | |
|
| | |
| |
| |
| | |
This reverts commit 95db661dc6be2ad6ed87f34094542660b9e0e155.
|
| | |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| | |
While it's true that TOML doesn't allow explicitly setting None values,
None is also used to represent a key not being in a table, which is a
valid thing to want in the case of a duration.
Fixes: #2611
|
| |/
|
|
|
| |
(If you drop a FileWatcher, the thread that makes it works will
exit.)
|
| | |
|
| |
|
|
|
|
|
| |
```bash
readarray -t bump < <(maint/list-crates | grep -P '^tor-|^arti-')
for crate in "${bump[@]}"; do cargo set-version --bump minor -p "${crate}"; done
```
|
| |
|
|
|
|
|
|
|
| |
We're about to *use* the fix that was in 1.11.4. We already updated
the lockfile in !4228, so this is just Cargo.toml changes (which will
prevent the minimal-versions tests failing when we change the code to
rely on the fix).
git-grep -l '^derive-deftly' |xargs perl -i~ -pe 's{\b\Q1.11.3\E\b}{1.11.4}g'
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Removed unnecessary lint
Closes #2556
See merge request tpo/core/arti!4210
|
| | | |
|
| | |
| |
| |
| | |
Removed unnecessary lint
|
| |/ |
|
| |\
| |
| |
| |
| | |
Upgrade itertools to 0.15.0
See merge request tpo/core/arti!4192
|
| | |
| |
| |
| |
| |
| | |
Additionally, fix itertools usage in maybenot_padding.rs
The definition of `Position` changed in 0.15.0.
|
| |\ \
| |/
|/|
| |
| | |
Added ConfigBuildError::MissingOneOf and did TODO
See merge request tpo/core/arti!4131
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Closes #2617.
We've lucked out this time, and it turns out that every one of our
published crates gets a minor bump. So this was generated with:
```
for cr in $(./maint/list-crates); do
cargo set-version -p $cr --bump minor
done
```
|
| |\ \
| | |
| | |
| | |
| | | |
Try out deftly $impl feature, mostly in tor-config
See merge request tpo/core/arti!4095
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | | |
Bump MSRV to 1.91
See merge request tpo/core/arti!4105
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit bumps the MSRV to 1.91 which was released on 2025-10-30.
The Cargo.toml files were updated as follows:
```sh
git ls-files | \
grep ".*Cargo\.toml$" | \
xargs sed -i '' 's/^rust-version = "1\.89"$/rust-version = "1\.91"/g'
```
The following files were updated manually:
```
modified: .gitlab-ci.yml
modified: README.md
modified: flake.nix
modified: maint/docker-android/Dockerfile
```
|
| |\ \
| |/
|/|
| |
| | |
Fix string_slice exceptions outside of netdoc
See merge request tpo/core/arti!4092
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
I want this in tor-netdoc (which doesn't use tor-config and probably
shouldn't).
Almost entirely code motion. Review with --color-moved.
|
| | |
| |
| |
| |
| |
| |
| | |
I want to mvoe this to tor-basic-utils, so it can't use tor-config in
its example. Also, Cell is just a nicer example.
(The rule identifier was already wrong.)
|
| |/
|
|
|
| |
IMO this makes the example clearer. It will also make moving this
macro to tor-basic-utils less noisy.
|
| |\
| |
| |
| |
| | |
Lint for clippy::string_slice
See merge request tpo/core/arti!4086
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This commit adds #[allow(clippy::string_slice)] to all functions in the
code where string slices are used, alongside a TODO comment.
We do this add the function header to have it consistent, as things like
expression based allow's are still experimental.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
| |
New beta semver policy means we should pin the patchlevel.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list-crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.43.0
done
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The non-{arti-,tor-} crates are:
```
./maint/list-crates | rg -v '^(tor|arti)'
oneshot-fused-workaround
web-time-compat
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
futures-copy
```
We split them in the following categories:
* crates with no changes (no version bumps):
```
oneshot-fused-workaround: No change.
web-time-compat: No change.
slotmap-careful: No change.
test-temp-dir: No change.
caret: No change.
safelog: No change.
retry-error: No change.
futures-copy: No change.
```
Obtained with:
```
maint/changed-crates -v "arti-v$LAST_VERSION" 2>&1 >/dev/null | grep -i "no change" | grep -v '\(tor\|arti\)-'
```
* crates that only have non-functional changes (bump the patch version,
but not the dependend-on version):
- equix
* crates where functional changes were made, but no APIs were broken
(bump patch):
- fs-mistrust
* crates where APIs were broken (bump minor):
- hashx
- fslock-guard
The bumps from this commit were created using this script:
```
PATCH_NF=(
equix
)
PATCH="
fs-mistrust
"
MINOR="
hashx
fslock-guard
"
./maint/bump-nodep "${PATCH_NF[@]}"
for crate in $PATCH; do
cargo set-version --bump patch -p $crate;
done
for crate in $MINOR; do
cargo set-version --bump minor -p $crate;
done
```
|
| | |
|
| |
|
| |
Co-authored-by: gabi-250 <[email protected]>
|
| |
|
|
|
|
|
|
| |
Some of the tests used derive(Builder), which is not current
practice for our configuration.
Additionally, they didn't implement the requisite ConfigBuilder
logic to pass with the other changes in this branch.
|
| |
|
|
|
|
|
| |
I've left the options here as booleans, but moved them into a
struct. (IMO, booleans are at their riskiest when they are passed
as function arguments, and much less risky when they are used as
struct fields.)
|
| |
|
|
|
|
| |
This functionality exposes the part of the configuration tree that
was actually used, along with any defaulted values. RPC will want
this.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 isn't strictly necessary, but it helps for consistency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This affects the automatic builder code made by our
derive_deftly macro. It is only relevant (for now)
in the case of the `NonZero<>` types and their special handling.
Previously, when a builder contained Option<U>,
and we wanted to generate a configuration holding T,
we would _first_ apply a transformation from Option<U> to Option<T>
and _second_ unwrap the result or apply a default.
Now, we _first_ convert from Option<U> to U by applying a default,
and only _then_ perform any necessary conversion from U and T.
This is only relevant in the case where U and T are different.
It simplifies writing the defaults for `NonZero` options,
and will significantly simplify the logic for setting builder defaults.
|
| |
|
|
| |
It previously referred to a function that didn't exist.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|