mirrors/arti.git/crates/tor-dirmgr/src/lib.rs, branch arti-v1.5.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.5.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.
Temporarily suppress mismatched_lifetime_syntaxes.2025-07-07T15:50:04ZGabriela Moldovangabi@torproject.org2025-07-07T15:50:04Zurn:sha1:a11b611466a5a73f5e06a0aabd17284a57d12fe3
See #2060.
*: suppress cognitive_complexity warnings from nightly2025-05-29T14:21:17ZNick Mathewsonnickm@torproject.org2025-05-21T14:48:35Zurn:sha1:5327d3e22a83b8469a5d4191d92e1364344ddc93
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
Rename recommended_protocols to protocol_statuses.2025-04-16T23:06:51ZNick Mathewsonnickm@torproject.org2025-04-16T11:59:00Zurn:sha1:461a2467f90dbd2bf4f4b900fc0816aa4c906fdb
This name reflects its purpose better than the original one,
since it includes required protocols as well as recommended ones.
protover, *: Add documentation about what "supported" means.2025-04-16T23:06:51ZNick Mathewsonnickm@torproject.org2025-04-14T00:42:31Zurn:sha1:11148719ba04aab37c7784d198018eeacced69c2Add warnings about removing supported protocols.2025-04-16T23:06:51ZNick Mathewsonnickm@torproject.org2025-04-07T15:27:42Zurn:sha1:ba612260ae603c8e5eba37206c21fd089afe075dnetdir: Add a recommended_protocols() to NetDirProvider2025-04-16T23:06:51ZNick Mathewsonnickm@torproject.org2025-04-07T14:59:29Zurn:sha1:42e01549f946f5f23ab004fe2ed82fc9279d8e8ddirmgr, netdir: Store protocol requirments as soon as they are validated.2025-04-16T23:06:51ZNick Mathewsonnickm@torproject.org2025-04-03T15:20:32Zurn:sha1:98f28d0b4c5c2b90ed732ed29d571f71a48c15b4New functions to report supported subprotocols2025-04-16T23:06:51ZNick Mathewsonnickm@torproject.org2025-04-02T18:00:00Zurn:sha1:efe36d15de88ec5b7f39db99f9d2a58e4e5db7ac
Part of #1849.
Note that these functions are distributed across crates,
so that if (in the future) we stop doing API breaks
with every release, we will get the right outputs.
Note also that these functions build the list of protocols
out of specific symbolic features, rather than numbers:
this makes it easier to avoid errors about "which feature was
Relay=4 again", and easier to avoid accidentally referring to a
protocol that doesn't exist, like "Consensus" (should be "Cons")
or "HsDir" (case is wrong).