mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.0 2024-10-30T16:55:19Z 2024-10-30T16:55:19Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-30T16:55:19Z urn: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 2024-10-24T01:35:05Z Nick Mathewson nickm@torproject.org 2024-10-24T00:33:55Z urn: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). 2024-10-24T01:35:05Z Nick Mathewson nickm@torproject.org 2024-10-22T13:54:24Z urn:sha1:d40e9be4da24a10ad753413b7959af160a54a663 2024-10-24T01:35:05Z Nick Mathewson nickm@torproject.org 2024-10-22T13:50:00Z urn: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. 2024-10-17T23:23:10Z Nick Mathewson nickm@torproject.org 2024-10-17T23:04:50Z urn: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 2024-10-17T23:16:58Z Nick Mathewson nickm@torproject.org 2024-10-16T18:58:58Z urn:sha1:5219f4cee5a74c0abdd8ad548b4ead9e2066cb2c These are not regular ErrorKinds, since they can never occur in an error that's meant to be returned from a Rust API like `arti-client`. Instead, they only exist for errors returned from RpcError. (I can't find the place where we discussed this previously, but the rationale is that if an ErrorKind never makes sense in response to something that the user does from Rust, we should never have that be an ErrorKind. The fact that the removed kinds do not actually appear outside the RPC system suggests that this is reasonable.) 2024-10-17T19:19:40Z Nick Mathewson nickm@torproject.org 2024-10-16T17:32:02Z urn:sha1:124038aaa8c9e85e773cc150c0732761f4cf9562 In some cases, the tor_error::ErrorKind names were nicer. 2024-10-17T19:19:40Z Nick Mathewson nickm@torproject.org 2024-10-15T21:07:31Z urn:sha1:74424b2dd0eed95b96096ed0267c71f3c8f70ae2 We'll use this to make RpcErrors directly, without having to go through an error that implements HasKind. Later, we'll add the ability to set the `data` fields on an RpcError. 2024-10-17T19:19:40Z Nick Mathewson nickm@torproject.org 2024-10-15T21:03:25Z urn:sha1:b7368d270364f15945dc3a81d81a7109a4e98a5d This change will let us start removing the not-entirely-logical `Rpc.*` variants from tor_error::ErrorKind. 2024-10-17T19:19:40Z Nick Mathewson nickm@torproject.org 2024-10-15T20:55:47Z urn:sha1:f57e69b890a704b813224a6bc0f12ad948b675f2