| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Calling it "singleton" might have suggested that it was using the
[singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern),
which it isn't.
(Renaming done with rust-analyzer and double-checked with `git grep`.)
Closes #1585.
|
| | |
| |
| |
| | |
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.
|
| |
|
|
| |
Without this, we get a warning when we run `cargo doc`.
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Per discussion, this field isn't really specified in a way that lets
us fill it sensibly at the moment. So for now, we're going to just
omit it.
Additionally, we said that we'd Report on our errors; this branch
changes the implementation of RpcError to do that.
Question: Will the blanket implementation for Into<RpcError> make
it harder to re-add a Data field later on if we want to do so?
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
These functions are called rarely enough that it is probably okay
for the ergonomics to be a bit verbose.
|
| | |
|
| | |
|
| |
|
|
|
| |
We've wanted separate error codes for "no such method exists" and
"this method exists, but this object doesn't have it."
|
| |
|
|
| |
This change would take some serde magic that is probably not worth it.
|
| | |
|
| |
|
|
| |
(There is no longer such a thing as a "pseudomethod.")
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| | |
|
| | |
|
