| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
Removed unnecessary lint
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
| |
Fixes several warnings from
cargo check --workspace --no-default-features
|
| |
|
|
|
|
|
|
| |
This method doesn't actually create a new stream; it creates a
single-use client object that can be used with SOCKS to launch
a new stream, and capture an RPC object for that stream.
Closes #1664.
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
|
|
|
| |
The application creates these, using a new-stream-handle RPC command,
on an object that can actually create streams.
Then later, the application provides the (global) identity of one of
these objects when it's making a SOCKS connection. This causes the
object to take hold of a `DataStreamCtrl`.
|
| |
|
|
| |
I think I'm going to add another stream management module here.
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| | |
|
| |
|
|
|
|
| |
This will later let us tell the session-creation function
how the authentication occurred, which will let it decide
what privileges to provide.
|
| | |
|
| |
|
|
|
| |
We'll want to move the responsibility for creating Sessions outside
the rpcmgr crate.
|
| |
|
|
|
|
|
| |
These identifiers are actually only "global" with respect to a given
`RpcMgr`, but they should not be forgeable or reusable across RpcMgr
objects. We're going to use them so that we have a kind of identifier
for `TorClient`s that we can expose to SOCKS.
|
| |
|
|
|
|
| |
This will make it easier to change the semantics of what exactly we
return, whether it has to be/contain a client, whether you can use
it to look up all the live objects, &etc.
|
| | |
|
| |
|
|
|
|
|
| |
To me, "Session" suggests that we're authenticated, when we are
not necessarily authenticated. Also, we may eventually want to have
some kind of persistent session object; if we do, then we'll want
Connections to be separate.
|
| |
|
|
|
|
| |
See the comments on `TypedAddr` for some explanations about
why this is so tricky. Thanks to @diziet for helping me figure
this out.
|
| |
|
|
|
|
|
|
|
| |
Now there's a module in `arti` that runs the loop for an RPC
listener. The part of the old `listener` module that made
the framed connections is now part of the `Session` object.
There is now yet another a temporary location for the pipe; we
should pick something better. At least now it's configurable.
|
| |
|
|
|
|
|
|
|
| |
In the future, this will probably hold more data as well, like a
TorClient and some configuration info.
The TorClient will present an issue; I've made comments about that.
Closes #820
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit big, but it's not that _complicated_.
The idea here is that we use serde's "untagged" enum facility
when parsing our `Request`s, such that if parsing as a `Request`
fails, we parse as an `InvalidRequest` and try to report
what the problem was exactly.
This lets us determine the ID of a request (if it had one),
so we can report that ID in our error message. We can also
recover from a much broader variety of errors.
We now also conform with the spec reporting errors about
completely wrong json, requests without IDs, and so on.
|
| | |
|
| |
|
|
|
| |
It requires tokio, it's unix-only, and makes some unfortunate
shortcuts. Probably good enough for initial testing.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Ordinarily you can cancel a future just by dropping it, but we'll
want the ability to cancel futures that we no longer own (because we
gave them to a `FuturesUnordered`).
|
| |
|