| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 9447e48d0c698d51c75706d5efedcd6142c82f2a, which
told Clippy to ignore a warning that (I think) no longer occurs.
(Clippy was complaining that we were _naming_ a function in a
const-context that wasn't const-stable at our MSRV. But it's fine
to _name_ a non-const function in that case: we just can't _call_
it.)
See https://github.com/rust-lang/rust-clippy/issues/15792 for more
info on the clippy bug.
AFAICT the warning no longer appears with current beta, nightly,
or stable versions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
We're about to use this error type for other things too.
|
| |
|
|
|
|
| |
There was formally a redundant method of this name, which could get
out-of-sync with invoke_without_dispatch. But now that method is
gone, and this TODO is wrong.
|
| |
|
|
|
|
|
|
|
| |
The current cancel code is prone to deadlock, so the easiest way to
solve it appears to be making cancel requests themselves
uncancellable.
I've included a test to verify the behavior; previously, this test
caused a deadlock.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
It is no longer necessary to say, for every RPC method,
that its error type is RpcError.
|
| |
|
|
|
|
| |
We have decided not to remove the "anybody can define methods"
property. This commit documents the consequences, and warns
extenders away from some really bad ideas.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Change `pub` to `export`
* Change the `=` in define to `:`
* Change `pub_template_semver_check` to `template_export_semver_check`
Right now, 0.12.1 supports both syntaxes. I have verified this branch
also compiles with
https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/merge_requests/402
ee171ffaf56d7dcb7d75584054921153fe19b222
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Now Methods can return anything; and only if their outputs are
Serialize will they implement RpcInvocable.
|
| |
|
|
|
|
| |
This will allow us to create dispatchable methods that are only
invoked from inside the arti code, and are not themselves
serializable.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to do this carefully, since we want our system to be
extensible with new namespaces.
First, when we are constructing an RpcMgr, we _warn_ about any
method names that are misformed.
Second, we add a test in the `arti` crate to fail if any method
names are invalid. This will only catch method names in crates that
`arti` depends on.
|
| |
|
|
| |
It no longer requires the user to have `typetag` in scope.
|
| |
|
|
|
|
|
|
|
| |
The trick here is to provide an `Invoker` trait,
with blanket implementations for appropriate `fn(_,_,_,_?) -> _`.
With this trick, we no longer need to have a `decl_rpc_invoke_fn`.
This lets us discard HasConstTypeId entirely,
and will let us simplify some other syntax moving forward.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We don't actually need this to be a trait; we just need
methods and objects to have a `CONST_TYPE_ID_` if they want to
participate in the inventory-based method registry.
Removing this trait makes it much simpler to declare methods and
objects.
|
| |
|
|
|
|
| |
This simplifies our implementation logic in a few places,
and simplifies our invocation syntax greatly. There are a few
infelicities, noted in `TODO RPC` comments.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Right now, this lets us say whether the method was unrecognized or
whether the parameter type was incorrect.
We'll use this to enforce correct method names later on.
(I have to add another `inventory` here, since the `typetag`
maintainer does not want to expose this functionality: see
https://github.com/dtolnay/typetag/issues/57#issuecomment-1506106290
)
|
| |
|
|
|
| |
Now `Method` has an Output and Update associated type, and
`decl_method` can do a little more.
|
| |
|
