mirrors/arti.git/crates/tor-rtmock, branch arti-v1.4.4mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.42025-06-05T10:33:57Zrelease: Bump all tor-/arti- crates to 0.31.0.2025-06-05T10:33:57ZAlexander Hansen Færøyahf@torproject.org2025-06-05T10:33:57Zurn:sha1:95180f80d7ab574a95368f3bca1e7b78555d479a
This was done using:
for crate in $(./maint/list_crates | grep -P '^tor-|^arti-'); do
cargo set-version -p $crate 0.31.0
done
./maint/cargo_sort: Run cargo-sort on the entire workspace.2025-05-27T13:32:26ZGabriela Moldovangabi@torproject.org2025-05-23T13:54:02Zurn:sha1:03885fdbf4ea19b9215e05cc557372758359f44d
The [latest version] of `cargo-sort` is more opinionated than the
previous one, and is now causing the `rust-checks` job to fail on
`main`.
This commit applies the fixes needed to satisfy the new `cargo-sort`
rules. These changes were generated by running `cargo sort --workspace`
several times, until `cargo sort --check --workspace` finally succeeded
(it couldn't fix all the errors in one go, for some reason).
I have omitted the changes `cargo-sort` made to the top-level
`Cargo.toml`, to preserve the topological ordering of the workspace
members.
Closes #2014
[latest version]: https://github.com/DevinR528/cargo-sort/blob/f066ae80e5e6f5c1d8f0e2b8099461dcb97d9656/changelog.md#200
*: use std::io::Error::other in many places2025-05-16T01:46:11ZNick Mathewsonnickm@torproject.org2025-05-16T01:46:11Zurn:sha1:30617ad94bed7d2e4829c10144daf202d3ffd23c
The `IoError::other` function is an easier way to say
`IoError::new(IoErrorKind::Other, ...)`. It's been around since
1.74, but clippy started warning about the more verbose version in
1.87.
rtmock: use Option::replace instead of mem::replace2025-05-16T01:39:48ZNick Mathewsonnickm@torproject.org2025-05-16T01:39:48Zurn:sha1:9aa5137a79ea9af627135d088468998a208cddbb
Option::replace has been around since 1.31,
but the clippy warning is new.
All crates: bump rust-version to 1.83.2025-05-13T18:46:28ZNick Mathewsonnickm@torproject.org2025-05-13T18:46:28Zurn:sha1:88e911acd4bb70bf1da0fc71d77b51cb6abde478release: Bump all unstable tor/arti crates to 0.30.02025-05-01T16:22:28ZWesley Aptekar-Casselsme@wesleyac.com2025-05-01T15:55:57Zurn:sha1:770aaa9648d42835b2c6b3b29f4051d287ddba88
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.30.0
done
```
Update rand requirement to 0.9.12025-04-29T22:52:26ZNick Mathewsonnickm@torproject.org2025-04-29T19:04:27Zurn:sha1:fc0810c1091b2ec606111ae94e726cf5f7b10b38
(This is going to be a _requirement_,
since rand 0.9.1 has a behavioral change from 0.9.0)
Run cargo update.2025-04-29T21:35:34ZWesley Aptekar-Casselsme@wesleyac.com2025-04-29T17:30:17Zurn:sha1:54e3933f577548f10e01ae9e979ffb110481f9b4
I updated everything except rand, because the new version of rand
interacts with #1903, thus requiring more care.
tor-rtcompat: task tests: Allow a clippy lint2025-04-10T16:22:19ZIan Jacksonijackson@chiark.greenend.org.uk2025-04-10T16:22:07Zurn:sha1:7fc0ec4f2161e1023a2243e207879d2dbd5c754d
This doesn't seem to happen with my local compiler. Anyway, suppress
it. I don't think we want to split up this function.
tor-rtcompat: task: Break out subthread_yield2025-04-10T14:34:34ZIan Jacksonijackson@chiark.greenend.org.uk2025-04-10T14:34:04Zurn:sha1:cedb3da4588b96eae0d6750f10fe43dd4d504a63
This gets rid of a clippy complaint about subthread_block_on_future
being too complicated.