mirrors/arti.git/crates/tor-rtmock/src/task.rs, branch arti-v1.7.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.7.02025-08-07T15:28:36ZSwitch Cargo.toml files to edition 2024.2025-08-07T15:28:36ZNick Mathewsonnickm@torproject.org2025-08-06T01:19:58Zurn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
Update code for Edition 20242025-08-07T15:28:31ZNick Mathewsonnickm@torproject.org2025-08-07T12:44:47Zurn:sha1:0453fb4be8cf618b94230812957ce1db1afe74bd
1. Run cargo fix --edition
2. Selectively revert the "if let"->"match" changes.
These changes are meant to protect us from the lifetime changes
for "if let" bindings in Rust 2024.
But we're not actually relying on the old lifetime rules
anywhere, and the match syntax here is quite ugly.
3. Automatically revert `$pat:expr_2021` to `$pat:expr`.
(We don't actually want to restrict the expression syntax
that our macros accept).
Done with
`git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'`
4. Run cargo fmt.
tor-rtmock: Use subthread_spawn for spawn_blocking.2025-06-09T18:07:22ZWesley Aptekar-Casselsme@wesleyac.com2025-06-09T17:45:00Zurn:sha1:1704d094a31013afafaac9f0fd87dcfa8db7f511
Fixes: #2033
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.
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.
tor-rtcompat: task tests: Allow a clippy lint2025-04-10T14:34:34ZIan Jacksonijackson@chiark.greenend.org.uk2025-04-10T14:26:39Zurn:sha1:c71aa81d5287531421adb2175ad68ef524d76d3btor-rtcompat: BlockOn: relax bounds on reenter_block_on2025-04-09T16:52:03ZIan Jacksonijackson@chiark.greenend.org.uk2025-04-07T16:58:45Zurn:sha1:2a7dc6c46274e0d96e773c031cabd5373483429e
The future no longer needs to be `Send + 'static`.
tor-rtmock: task: subthread_block_on_future; Yield a bit more2025-04-09T16:52:03ZIan Jacksonijackson@chiark.greenend.org.uk2025-04-09T16:20:16Zurn:sha1:a56e724360f6c1e33e892970b88f651296e79af7tor-rtmock: task tests: New subhtread_pingpong test2025-04-09T16:52:03ZIan Jacksonijackson@chiark.greenend.org.uk2025-04-09T15:39:09Zurn:sha1:eadb6e980fe2b8acc8d6ea3b1ea8d7c8aa2cc188
This test demonstrates that the intended use pattern compiles and
works.
It couldn't exist until now because we couldn't conveniently make a
`Send + 'static` future out of `rx.next()`.