| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
rpc: Rename SingletonId to SingleIdResponse
Closes #1585
See merge request tpo/core/arti!2448
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
|
|
|
|
| |
(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`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
| |
These functions are called rarely enough that it is probably okay
for the ergonomics to be a bit verbose.
|
| |
|
|
| |
This change would take some serde magic that is probably not worth it.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
add_warning/CI: New strategy to avoid "unexpected-cfgs" warning
Closes #1395
See merge request tpo/core/arti!2129
|
| | |
| |
| |
| | |
This commit is automatically generated.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Now the update sink is its own boxed object. It is not yet passed
to the invoke functions that want it.
|
| | |
|
| | |
|
| |
|
