| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is a bit complicated since:
- Using cbindgen with macro expansion requires a nightly rust:
so, we have to look for one.
- There are some cbindgen warnings which I cannot find any way to
suppress, so instead of giving all warnings, it seems better to
give a diff from the old list of warnings to the new list.
|
| |
|
|
|
|
|
|
|
| |
This only covers the absolute minimal API in order to launch a
connection and run simple requests, and it doesn't document anything
nearly well enough. Nonetheless I think it's good enough for an
initial review, to make sure that we've got the basics right (as
well as a general consensus on the error handling API, naming, and
so forth).
|
| |
|
|
| |
(Internally, it is a boxed CStr that is always UTF-8.)
|
| |\
| |
| |
| |
| |
| |
| | |
tor-dirmgr: Return an error if storage is readonly and DB is missing/incompatbile.
Closes #1497
See merge request tpo/core/arti!2283
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
missing/incompatbile.
This fixes a bug in `SqliteStore`'s constructor: previously, it would
unconditionally try to create the missing database, even if it didn't
have write access. As a result, it was impossible to reliably start
multiple concurrent arti processes configured with the same (empty or
nonexistent) cache_dir, because many of them would fail with errors such
as
```
attempt to write a readonly database: Error code 8: Attempt to write a readonly database
```
Returning a `LocalResourceAlreadyInUse` error kind here enables us to
leverage the retry loop from `TorClientBuilder::create_unbootstrapped`
(which retries on local resource errors if `local_resource_timeout` is
set).
Closes #1497
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
arti: Add tests for the hss/hsc subcomands
Closes #1250
See merge request tpo/core/arti!2275
|
| | | | |
|
| | |/
| |
| |
| | |
Closes #1250
|
| |\ \
| | |
| | |
| | |
| | | |
tor-rtmock docs: Improve discussions of mocked time
See merge request tpo/core/arti!2286
|
| | | | |
|
| | |/
| |
| |
| | |
Improve/replace some out-of-date notes in the docs.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
(This will either become used later, or we will remove it;
the TODO RPC will remind us.)
|
| |
|
|
|
|
|
| |
This warning suggests using `[a,b]` as a Pattern
when it sees a search for `|ch| ch == a || ch == b`.
(All of our supported rust versions allow this kind of Pattern.)
|
| |
|
|
|
| |
This warning complains when we say `where T: SomeTrait + ?Sized`
when `SomeTrait` is inherently Sized.
|
| |\
| |
| |
| |
| | |
rpclib: Use i64 rather than u64 for request IDs.
See merge request tpo/core/arti!2279
|
| | |
| |
| |
| | |
This makes it conform to the spec and match arti-rpcserver.
|
| |\ \
| | |
| | |
| | |
| | | |
rpcbase: Fix most TODO RPC comments.
See merge request tpo/core/arti!2284
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.")
|
| | | |
| | |
| | |
| | |
| | | |
See
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2280#note_3051134
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2280#note_3051270
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2280#note_3051268
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| | |
I'm not particularly pleased with this name. We need names for both
the type, and the trait we'll almost certainly want to introduce in
the future.
|
| | | |
|
