mirrors/arti.git/maint, branch arti-v2.1.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.1.02026-03-02T17:42:42ZBump all the unstable tor- and arti- crates to 0.40.0.2026-03-02T17:42:42ZGabriela Moldovangabi@torproject.org2026-03-02T17:42:42Zurn:sha1:404764338e0f5df7209c89c4a48ad50e53423bd1
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.40.0
done
Bump the versions of the non-{arti-,tor-} crates2026-03-02T17:36:23ZGabriela Moldovangabi@torproject.org2026-03-02T17:36:23Zurn:sha1:d45c09c8e808c90c4fcb5416fd52c3c138b4871a
The non-{arti-,tor-} crates are:
```
./maint/list-crates | rg -v '^(tor|arti)'
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
futures-copy
```
Because this release bumps the MSRV, I am bumping the minor version of all of
them.
MINOR="
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
futures-copy
"
for crate in $MINOR; do
cargo set-version --bump minor -p $crate;
done
```
Allow clippy::collapsible_if to trigger2026-02-16T15:22:24ZGabriela Moldovangabi@torproject.org2026-02-09T11:49:02Zurn:sha1:ade1d59e8e44c93b6ee447b72a2948a9652ec44e
`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.
Bump MSRV from 1.86 to 1.892026-02-16T15:22:24ZGabriela Moldovangabi@torproject.org2026-02-09T11:29:39Zurn:sha1:c48a2ba6771016e7c57f02cfb99d62c3e5b34bc4
As agreed at our last team meeting.
See
https://gitlab.torproject.org/tpo/core/arti/#minimum-supported-rust-version
Bump time to 0.3.472026-02-16T14:55:04ZGabriela Moldovangabi@torproject.org2026-02-09T11:04:54Zurn:sha1:5c5eaae7ae57ed68a3b0ff4ac1e84101c8e71361
This enables us to un-ignore RUSTSEC-2026-0009.
See #2341 for analysis of impact.
Merge branch 'bump-min-async-io' into 'main'2026-02-09T20:47:49ZDavid Gouletdgoulet@torproject.org2026-02-09T20:47:49Zurn:sha1:de4110de9b4f9c4585dcbdbfea0ceca6b33b757d
downgrade-dependencies: require async-io 1.1.5.
Closes #1168
See merge request tpo/core/arti!3660Merge branch 'cargo-metadata-all-features' into 'main'2026-02-09T19:37:52ZNick Mathewsonnickm@torproject.org2026-02-09T19:37:52Zurn:sha1:2e75d3647d5cb803f720b0fd42d4a3d995336a06
Set package.metadata.docs.rs.all-features to true for all crates
Closes #2307
See merge request tpo/core/arti!3656downgrade-dependencies: require async-io 1.1.5.2026-02-09T16:19:57ZNick Mathewsonnickm@torproject.org2026-02-09T14:08:31Zurn:sha1:5fba73f705e252b91f8429ee2b2f1084c9737092
In my testing, this appears to fix #1168, an intermittent test
failure. The underlying cause of the failure appears to be
a surprise blocking return old async-io versions:
> The problem was in that random yielding inside
> AsyncRead/AsyncWrite (which is supposed to prevent task starvation
> when I/O never returns the WouldBlock error) doesn't play nice
> with the TLS protocol. It seems that TLS handshake fails if a
> write errors with WouldBlock.
-- https://github.com/smol-rs/async-io/issues/31
I think the problem here might actually be something more subtle
than _that_, since WouldBlock on an underlying write is totally
legit. But this appears to fix the testing issue at least.
maint/cargo-audit: Ignore RUSTSEC-2026-0009 for now2026-02-09T12:55:39ZGabriela Moldovangabi@torproject.org2026-02-09T12:55:39Zurn:sha1:36ed8614d06300eb03c34a817bb44bcc4636dd46
See
https://gitlab.torproject.org/tpo/core/arti/-/issues/2341#note_3339657
ci: Check crates configure features published to docs.rs2026-02-09T01:34:03ZNiel Duysterscontact@ndvibes.com2026-02-09T01:21:37Zurn:sha1:d4d7f9f1c6aa542f24f8abe8fe44f8f74a3ed9e1
All (publishable) crates should explicitly configure what features to (not) document in docs.rs.
This to avoid our documentation containing references to public API specifications which yield "given resource not found"
due to them being behind a feature flag not being published to docs.rs by default.