mirrors/arti.git/crates/tor-rpcbase, branch arti-v1.3.2mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.22025-01-07T16:01:41ZBump versions of internal arti crates for Arti 1.3.22025-01-07T16:01:41ZNick Mathewsonnickm@torproject.org2025-01-07T14:46:55Zurn:sha1:8f4297f5e2712213910b50ced205c7b5aa0619b5
The affected crates follow our regular versioning.
They all get bumped to 0.26.0.
Done with
```
for crate in $(./maint/list_crates |grep '^arti-\|tor-' ); do
cargo set-version --bump minor -p $crate;
done
```
clippy: deny `mod_module_files`2025-01-06T23:09:41ZSteven Engleropara@torproject.org2025-01-06T23:02:49Zurn:sha1:252a3a803b2db65792db5bd51dee8950d8557e0d
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
add_warnings, *: Allow clippy::needless_lifetimes2024-12-03T14:27:26ZNick Mathewsonnickm@torproject.org2024-12-03T14:15:50Zurn:sha1:64cc3f2ed3eea0b7c5cc89ae07cbdadfdc1646fb
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
Bump all the unstable tor- and arti- crates to 0.25.0.2024-12-02T15:41:21ZGabriela Moldovangabi@torproject.org2024-12-02T15:39:29Zurn:sha1:e29e7a9aab4312af6a35818cb01676376d888e49
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.25.0
done
```
cargo: Update `thiserror` to `2`2024-11-12T17:00:30ZClara Englercve@cve.cx2024-11-12T10:04:54Zurn:sha1:2f00918ad55881fb8fb37ad51eb644c8aaa16a23Bump unstable tor-* and arti-* crates to 0.24.02024-10-30T16:55:19ZIan Jacksonijackson@chiark.greenend.org.uk2024-10-30T16:55:19Zurn:sha1:08ff96ea214b3f4841aac10db77815e5e52c35d0
cargo set-version -p tor-async-utils 0.24.0
cargo set-version -p tor-basic-utils 0.24.0
cargo set-version -p tor-bytes 0.24.0
cargo set-version -p tor-cell 0.24.0
cargo set-version -p tor-cert 0.24.0
cargo set-version -p tor-chanmgr 0.24.0
cargo set-version -p tor-checkable 0.24.0
cargo set-version -p tor-circmgr 0.24.0
cargo set-version -p tor-config 0.24.0
cargo set-version -p tor-config-path 0.24.0
cargo set-version -p tor-consdiff 0.24.0
cargo set-version -p tor-dirclient 0.24.0
cargo set-version -p tor-dirmgr 0.24.0
cargo set-version -p tor-error 0.24.0
cargo set-version -p tor-general-addr 0.24.0
cargo set-version -p tor-geoip 0.24.0
cargo set-version -p tor-guardmgr 0.24.0
cargo set-version -p tor-hsclient 0.24.0
cargo set-version -p tor-hscrypto 0.24.0
cargo set-version -p tor-hsrproxy 0.24.0
cargo set-version -p tor-hsservice 0.24.0
cargo set-version -p tor-key-forge 0.24.0
cargo set-version -p tor-keymgr 0.24.0
cargo set-version -p tor-linkspec 0.24.0
cargo set-version -p tor-llcrypto 0.24.0
cargo set-version -p tor-log-ratelim 0.24.0
cargo set-version -p tor-memquota 0.24.0
cargo set-version -p tor-netdir 0.24.0
cargo set-version -p tor-netdoc 0.24.0
cargo set-version -p tor-persist 0.24.0
cargo set-version -p tor-proto 0.24.0
cargo set-version -p tor-protover 0.24.0
cargo set-version -p tor-ptmgr 0.24.0
cargo set-version -p tor-relay-crypto 0.24.0
cargo set-version -p tor-relay-selection 0.24.0
cargo set-version -p tor-rpcbase 0.24.0
cargo set-version -p tor-rtcompat 0.24.0
cargo set-version -p tor-rtmock 0.24.0
cargo set-version -p tor-socksproto 0.24.0
cargo set-version -p tor-units 0.24.0
cargo set-version -p arti-client 0.24.0
cargo set-version -p arti-relay 0.24.0
cargo set-version -p arti-rpc-client-core 0.24.0
cargo set-version -p arti-rpcserver 0.24.0
rpc: Simplify method-dispatch-bypass logic a bit2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-24T00:33:55Zurn:sha1:eb1d9acd10c5d500f56d637a7bba3acdd67dc9e8
This commit removes the separate function for asking whether to
bypass the dispatch code. Instead, it gives the "invoke with
bypass" function an error to return when no dispatch is warranted,
and moves the whole responsibility for method dispatch or
non-dispatch back into tor-rpcbase.
I had to add an ObjectId argument to `invoke_rpc_method` to make
this work, but that's probably a good thing.
Additionally, this commit tweaks the derive-deftly macro to prevent
you from asking for dispatch bypass on special methods, where it
isn't implemented (and doesn't really make sense).
rpc: do not attempt to dispatch methods with bypassed dispatch.2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-22T13:54:24Zurn:sha1:d40e9be4da24a10ad753413b7959af160a54a663rpc: Add a mechanism for method that bypass regular dispatch2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-22T13:50:00Zurn:sha1:d6367f61169fd21830aeb37d8952b9f6792cb115
I'm about to use this for rpc:release, which is special
because it doesn't actually look at the type of the object that it's
invoked on. Later it might be useful for manipulating weakrefs,
cloning referenes, detecting reference equality, etc.
rpc: Include "data" field in error.2024-10-17T23:23:10ZNick Mathewsonnickm@torproject.org2024-10-17T23:04:50Zurn:sha1:b126228d3297596113e187d2793cf7aa79bd8a34
In older versions of the rpc spec, this field held a serialized
version of the Arti error object. That's no longer the design: now
it provides a way for specific errors to include extra, specified,
machine-readable data. For more information see the section
"Errors" in rpc-meta-draft.md