| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This fixes a nightly clippy warning.
|
| |
|
|
|
| |
We haven't decided how these should work (see #868), so having them
present by default is a bad idea.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
| |
Closes #1624.
|
| |
|
|
|
|
|
| |
When specifying a delegation, the template user must also say what
type they're delegating to.
We're going to use this to document and expose delegations.
|
| | |
|
| |
|
|
|
|
|
|
| |
(Couldn't use Deref here, since we needed to get an Arc.)
Only one delegation target per object is permitted for now.
This will help with #1523.
|
| | |
|
| |
|
|
|
| |
We'll need this to refer to the names of RPC methods as visible to
the caller, and to cross-reference them with their related types.
|
| |
|
|
|
|
| |
Previously, we exposed them only via `describe_invocable`, which
would have required the caller to parse a string in order to find
these.
|
| |
|
|
|
| |
It is no longer necessary to say, for every RPC method,
that its error type is RpcError.
|
| |
|
|
|
|
|
| |
These methods were defined on DispatchTable, and then replaced by
top-level functions in the crate. (The reason for using top-level
functions instead is so that we get the locking on the dispatch
table correct.)
|
| |
|
|
|
| |
The duplication is only a few lines. I've looked into a couple of
ways for removing it, but they make the code flow even less clear.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Every method is either "special" or not; therefore, it is always a
Bug if we look for an rpc_invoker and don't find one.
|
| | |
|
| |
|
|
|
|
|
|
| |
Doing it this way will allow us to invoke methods without holding
the read lock on the table, implicitly or via the future.
I am not yet removing the methods on DispatchTable, since the tests
need them; I've added TODOs to revisit and remove later.
|
| |
|
|
|
|
|
|
| |
Formerly we used a Box. That was okay at first, but now that we
want RPC methods to be able to invoke other RPC methods, we don't
want the Invocable methods to have to consume the Context.
This requires that Context become Sync.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We need to do this so that we can actually invoke RPC functions
from one another.
|
| | |
|
| | |
|
| |
|
|
|
| |
Now that Method::Error exists, we can downcast Any to the actual
function's return type.
|
| |
|
|
|
|
|
|
| |
This is needed so that we can cast special methods' return types
properly.
I wish I could make this optional, but Rust doesn't allow
defaulting an associated type.
|
| |
|
|
| |
A @special invoker does not get an RPC entry.
|
| |
|
|
|
| |
Now Methods can return anything; and only if their outputs are
Serialize will they implement RpcInvocable.
|
| |
|
|
|
| |
RpcInvocable will only be implemented on types whose output
can be serialized.
|
| |
|
|
| |
This is part of work on #1403.
|
| | |
|
| |\
| |
| |
| |
| | |
tor-rpcbase: Use Void to eliminate a panic, as statically unreachable
See merge request tpo/core/arti!2124
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2103#note_3024372
I overlooked this.
|
| |
|
|
|
|
| |
Previously, one of the macros was documented to accept
`(function_expr)`, but in fact it would only accept an identifier.
Now we *do* accept any expression.
|
| |
|
|
|
|
|
|
| |
IMO if we want flags again in the future, we should probably pick a
syntax that doesn't involve such awkward patterns.
Perhaps `$expr $( , $( $flag )* )?`.
But I think we probably won't need that feature.
|
| |
|
|
|
| |
This renders the Update flag redundant.
Indeed, in this commit we mow ignore the flags.
|
| |
|
|
|
|
|
|
|
| |
This arm puts parens around its argument. But the other arm insists
on $func:ident, and also would capture any reasonable input.
This was probably something to do with the (func_expr) syntax. We
don't need to *fix* this macrology, because in a moment the whole
macro can be made to take $func:expr.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
