| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
(This function manipulates an ArtiRpcStatus;
and we try to have all of the ffi functions in this library
begin with "arti_rpc_".)
|
| | |
|
| |\
| |
| |
| |
| | |
ffi: Build arti-rpc-client-core as a C dynamic library.
See merge request tpo/core/arti!2331
|
| | | |
|
| | |
| |
| |
| |
| | |
This API allows the caller to launch a request and then watch for
updates on it.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Previously, we had in_ptr_opt for functions that want to take
a nullable `*const T` without consuming it.
This is the equivalent for taking a nullable `*mut T` without
consuming it.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Previously, we had out_ptr_opt for functions that wanted to return a
newly allocated `ArtiRpcFoo` via a `struct ArtiRpcFoo **` argument.
But we didn't have a way to return non-allocated `int` via an `int
*` argument. This code provides that.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
For some reason, we wound up - not with anything missing in the
header - but with extra warnings in our expected warnings file.
I'm tentatively blaming the git merge algorithm, or perhaps
the phase of the moon.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Don't need to tell docs.rs to enable `docsrs` cfg. It does it automatically as of https://github.com/rust-lang/docs.rs/pull/2390#event-11664409098
While this change isn't in our MSRV yet, we were only using this when building for docs.rs, where we use the latest anyway.
See merge request tpo/core/arti!2308
|
| | | |
| | |
| | |
| | |
| | | |
It now does it automatically, see
<https://docs.rs/about/builds#detecting-docsrs>.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Test cbindgen correctness in CI
Closes #1502
See merge request tpo/core/arti!2320
|
| | | | |
| | | |
| | | |
| | | | |
(This is kind of thing that the CI script should remind us to do.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This name change should emphasize that the (module-private)
`ParsedRequestFields` type is only for parsing, and we aren't
supposed to actually construct them for our own requests.
With this change, and the others on the branch, there's no longer a
risk of trying to serialize a ParsedRequestFields (since it doesn't
implement Serialize), or to deserialize a Request (since it doesn't
implement Deserialize).
Closes #1511.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As with responses, we previously used a strategy that could have
failed in the future, if we forgot to add an "unexpected_fields"
member to one of our structs.
Closes #1512.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This lets us make a couple of types module-private,
and prepares the way for using the serde_json::Value trick on
requests too.
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This approach keeps the property that we still preserve any
unrecognized fields, but takes a different approach. Instead of
using our own `structs` to round-trip the json, we use a
`serde_json::Value`, to ensure that we cannot forget to add the
`unexpected_fields` element to a struct.
|
| | | |
| | |
| | |
| | | |
(Without this, it isn't actually possible to use the RPC subsystem.)
|
| | |/
|/|
| |
| | |
This will enable us to return it to FFI callers as a nul-terminated string.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
rpc-client-core: Always re-encode requests and responses, and preserve unrecognized struct fields.
Closes #1491
See merge request tpo/core/arti!2312
|
| | | |
| | |
| | |
| | | |
This enable a `meta` object to have no `updates` field set.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to re-encode responses to avoid possible mismatch between
how arti-rpc-client-core parses messages and how the user application
parses messages. (In theory this shouldn't be necessary so long as
arti-rpc-client-core and arti have the same json implementation,
and arti-rpc-client-core is only used for talking to arti.
But those assumptions might change in the future.)
Closes #1491.
We want to preserve fields so that, if Arti adds any new elements
to response or error in the future, and the client knows about them,
they won't be lost simply because arti-rpc-client-core hasn't heard
of them.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
When writing a request, we want to keep any fields that we don't
recognize, in case the application (and arti) know about some
field that we haven't heard of.
|
| | |/
| |
| |
| | |
(They are about to diverge even further.)
|
| |\ \
| | |
| | |
| | |
| | | |
Fix a pair of typos in an ffi comment.
See merge request tpo/core/arti!2310
|
| | |/ |
|
| | |
| |
| |
| | |
Closes #1501.
|
| | |
| |
| |
| | |
(This is an errno or a GetLastError.)
|
| |/
|
|
|
| |
This will make error outputs more usable, and will make it possible
to expose OS error codes.
|
| |
|
|
|
|
|
|
|
|
| |
This is the result of:
```
for crate in $( ./maint/list_crates |grep '^\(tor\|arti-\)' ); do
cargo set-version -p $crate 0.21.0
done
```
|
| | |
|
| |
|
|
|
| |
Rust 1.70 (our MSRV) will not allow us to use a trait from a private
module in this way, unfortunately.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Except for *error_out, they are always set to NULL on error.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Additionally, inline the related conversion functions.
This should reduce the total amount of unsafe code that somebody
would need to look at.
|
| | |
|
| | |
|
| |
|
|
| |
(Documentation movement still needed.)
|
| | |
|
| | |
|
| | |
|
