| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
| |
* Bump in Cargo.toml
* Deal with `${Xmeta as ...}` incompatible change, by
always specifying an `as`, and changing `as tokens`.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
Previously we could only downcast to &dyn Trait,
which is not adequate.
|
| |
|
|
|
| |
This makes `ObjectRefExt` less necessary, and will let us make it
Arc-only.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-rpcbase: Use Void to eliminate a panic, as statically unreachable
See merge request tpo/core/arti!2124
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
add_warning/CI: New strategy to avoid "unexpected-cfgs" warning
Closes #1395
See merge request tpo/core/arti!2129
|
| | |/
| |
| |
| | |
This commit is automatically generated.
|
| | | |
|
| | | |
|
| |/
|
|
| |
It no longer requires the user to have `typetag` in scope.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we've done more refactoring, it's no longer necessary to
have this machinery, since:
* We can support statically registering instantiated methods, if we
know them ahead of time.
* Writing an installer function is pretty simple, and the syntax
is much nicer than the special-purpose junk we had before.
I've added examples of both approaches.
While we're at it, I've simplified the syntax for `invoker_ent!` a
little, since the parentheses I had before aren't necessary.
|
| |
|
|
|
| |
These are no longer needed, since they are inferred from the types
of the functions.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
