| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Since we can't enumerate every instantiation at compile time,
we instead provide a macro to generate an _installer_ function
that installs a set of functions for a given instantiation.
Due to the limitations of macro_rules, the syntax for generics is
a bit ugly.
|
| |
|
|
|
| |
Now there is an `decl_rpc_invoke_fn` macro that *only* declares the
type-erased functions. Another macro's job will be to register it.
|
| |
|
|
|
|
|
|
| |
This will be called _static_ to make it clear that it registers the
method statically, so you don't need to install it at runtime.
After a bit more work, there will be a separate macro that declares
an installer function.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a rather tricky piece of functionality. It works as
follows.
We introduce a `CastTable` type. Each `CastTable` tells us how to
downcast `dyn Object` for objects of a single concrete type.
The `Object` type now has a `get_casttable` method that returns
an empty `CastTable` by default.
`CastTable` is, internally, a map from the `TypeId` of the target
dyn Trait reference type to a function
`fn(&dyn Object) -> &dyn Trait`. These functions are stored as
`Box<dyn Any + ...>`. (They are Boxed because they may refer to
generic functions, which you can't get a static reference to,
and they're Any because the functions have different types.)
The `decl_object!` macro now implements `get_casttable` as
appropriate. (The syntax is a bit janky, but that's what we get
for not using derive_adhoc.) For non-generic types, `get_casttable`
uses a Lazy<CastTable>`. to initialize a CastTable exactly once.
For generic types, it use a `Lazy<RwLock<HashMap<..>>` to
build one CastTable per instantiation of the generic type.
This could probably be optimized a bit more, the yaks could be
shaved in a more scintillating hairstyle, and the syntax for
generic `decl_object` could definitely be improved.
|
| | |
|
| |
|
|
|
|
|
| |
Rationale: Our weak-vs-strong design is a bit confused at the moment
due to concerns about deduplication and capability semantics. It's
not clear that a general "change strong to weak" method is
compatible with what we want to provide.
|
| |
|
|
|
|
|
|
|
|
|
| |
I've made doing some design choices here:
* Reserving "rpc" as a prefix for post-authentication
functionality that is not arti-specific.
* Declaring these to be methods on the session rather than methods
on the objects themselves.
There's a problem with defining an API to drop a weak reference; see
comment in code.
|
