| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Consultation with a nearby Python expert, on another topic, revealed
that without --strict, mypy turns most of its stuff off by default.
Sadly (?) this bureaucracy didn't find any bugs.
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
Proto: Refactor Channel to always be Arc.
See merge request tpo/core/arti!2163
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously ChannelDetails had a double duty: It held elements shared
among the clones of a Channel, and it also held elements shared
between the Channel and the Reactor. But now that Channel doesn't
have to implement Clone, we can more the non-Reactor elements into
Channel itself.
This change may improve cache locality a bit, and should make it a
little easier to follow the channel code.
I've also moved unique_id out of ChannelDetails into Channel _and_
Reactor: it is small, immutable, and used all the time in logging.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This serves three purposes:
* It removes the 'send a cell' method from the channel's public
API. Nothing outside of tor-proto should have to use this.
* It paves the way for giving each circuit a separate handle onto
the channel's send functionality. This will eventually let
the channel multiplex among circuits more intelligently.
* It prepares for the next commit, which will make Channel itself
universally Arc<.>ed.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
For all mutable shared state, we ought to know which part of the
program sets it, which part of the program reads it, and why.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
chanmgr: Delegate to Channel::engage_padding_activities explicitly.
See merge request tpo/core/arti!2164
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
(This isn't a bugfix, but it helps avoid the appearance of a
function calling itself. This _would_ become a bug if we imported
the wrong trait into scope here.)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Downgrade Cargo.lock to previous libc crate version
See merge request tpo/core/arti!2166
|
| |/ / /
| | |
| | |
| | | |
The current version has been yanked.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Add two blank lines to CHANGELOG.
See merge request tpo/core/arti!2165
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
CI: Move cargo clean section to after_script.
See merge request tpo/core/arti!2159
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Part of arti#1410.
The idea here is to consolidate `cargo clean` in an after_script
section we call everywhere, rather than have it be in one that we
can forget to copy.
We can't call `cargo clean` unconditionally, though, since some of
our jobs don't install cargo. So we make sure it's there.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Allow RPC methods with non-serializable types
Closes #1403
See merge request tpo/core/arti!2152
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We need to do this so that we can actually invoke RPC functions
from one another.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Now that Method::Error exists, we can downcast Any to the actual
function's return type.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is needed so that we can cast special methods' return types
properly.
I wish I could make this optional, but Rust doesn't allow
defaulting an associated type.
|
| | | | |
| | | |
| | | |
| | | | |
A @special invoker does not get an RPC entry.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Now Methods can return anything; and only if their outputs are
Serialize will they implement RpcInvocable.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
RpcInvocable will only be implemented on types whose output
can be serialized.
|
| | | | |
| | | |
| | | |
| | | | |
This is part of work on #1403.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will allow us to create dispatchable methods that are only
invoked from inside the arti code, and are not themselves
serializable.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Provide and run script for making/checking link blocks in CHANGELOG.md
Closes #1388
See merge request tpo/core/arti!2126
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3030954
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Suggested here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3026423
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3026420
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 4e89a891206ec8e732bb33ae59844d6afe393333.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3026424
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This add link definitions that are missing, and deletes ones that are
unused.
This is precisely the results of
maint/update-md-links CHANGELOG.md
I have given it a cursory human review.
|
| | | | | | |
|
| | | | | | |
|