| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | |/ / / /
|/| | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We can actually return references here instead of `impl Deref`,
simplifying this code a bit and follow-on code to use this in
StreamPollSet.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Primarily I wanted to exercise the code path that we get a spurious
wakeup due to a future that was removed from the map later becoming
ready.
I also ended up merging ReadyFut and PendingFut into a more flexible
ValueFut to make this a little nicer.
|
| | | | | | |
|
| | | | | | |
|
| | |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of wrapping `FuturesUnordered`, which doesn't support efficient
access to its internal futures, keep the futures themselves in our own
HashMap, and use a custom Waker to be notified which futures are ready
to be polled.
*Almost* a pure refactor in this step - the implementation now requires
that keys are `Send + Sync + 'static` so that we can put them inside an
`Arc` and send them over a channel.
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | | |
tor-keymgr: Add private RelKeyPath type for relative paths.
Closes #1494
See merge request tpo/core/arti!2291
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`fs-mistrust` always maps `io::ErrorKind::NotFound` to
`fs_mistrust::Error::NotFound`, so these `io::ErrorKind::NotFound`
branches were unreachable.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We now use `CheckedDir::metadata()` to check if the path exists and is
of the correct type.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This makes `rel_path` return a `RelKeyPath` instead of a `PathBuf` to
prevent the accidental misuse of relative key paths (like the one
from #1492).
Closes #1494
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
FFI: Expose the objectID for the session object
See merge request tpo/core/arti!2318
|
| | | | | |
| | | | |
| | | | |
| | | | | |
(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.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
tor-proto: fix streammap panic
Closes #1513
See merge request tpo/core/arti!2319
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes #1513
|
| | |/ / /
| | | |
| | | |
| | | | |
For debugging #1513
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
maint/check_doc_features: Fixes for use with "pub mod restricted discovery"
See merge request tpo/core/arti!2316
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The module is correctly documented as "only available on crate feature
restricted-discovery" without it.
|
| | | | | | |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Without it, if the `restricted-discovery` feature is compiled out, the
module gets documented as:
```
Non-restricted-discovery (Available on non-crate feature `restricted-discovery`
only)
```
which is inaccurate.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Don't require TRANSPORT for PT STATUS messages.
See merge request tpo/core/arti!2307
|
| | | | |
| | | |
| | | |
| | | | |
See: tpo/core/arti#1488.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch changes the PT STATUS handler to not require the presence of
the `TRANSPORT` field in the K/V line. This matches current behaviour of
C Tor and was requested by the Anti-censorship Team at an earlier point
to enable STATUS messages to work for situation where it's not transport
specific messages.
To avoid future issues, we simply ignore any required keys right now
even though TYPE is to be expected.
See: tpo/core/torspec#267
See: tpo/core/torspec!63
See: tpo/core/arti#1488
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
shadow test: Add tests for restricted discovery hidden services
See merge request tpo/core/arti!2272
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This helped me debug some shadow test failures.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|