| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| | |
This is mostly code motion.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-config-path: new crate containing moved `tor_config::path`
See merge request tpo/core/arti!2590
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is a direct move of the `path` module from tor-config.
|
| | |/ |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
tor-error: use `Display` for backtrace captured by `BugRepr`
Closes #1713
See merge request tpo/core/arti!2588
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before:
```text
2024-10-29T01:57:31Z ERROR arti: error: internal error (bug) at crates/arti/src/lib.rs:378:27: foo
Backtrace [{ fn: "tor_error::internal::ie_backtrace::capture", file: "./crates/tor-error/src/internal.rs", line: 21 }, { fn: "tor_error::internal::Bug::new_inner", file: "./crates/tor-error/src/internal.rs", line: 105 }, { fn: "tor_error::internal::Bug::new", file: "./crates/tor-error/src/internal.rs", line: 94 }, { fn: "arti::main_main", file: "./crates/arti/src/lib.rs", line: 378 }, ...
```
After:
```text
2024-10-29T01:58:23Z ERROR arti: error: internal error (bug) at crates/arti/src/lib.rs:378:27: foo
0: tor_error::internal::ie_backtrace::capture
at ./crates/tor-error/src/internal.rs:21:27
1: tor_error::internal::Bug::new_inner
at ./crates/tor-error/src/internal.rs:105:24
2: tor_error::internal::Bug::new
at ./crates/tor-error/src/internal.rs:94:9
3: arti::main_main
at ./crates/arti/src/lib.rs:378:27
...
```
|
| |\ \
| |/
|/|
| |
| | |
tor-config: use 'path' feature of shellexpand
See merge request tpo/core/arti!2583
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
tor-chanmgr: revert `PendingChannelHandle` drop behaviour, and try to prevent problematic code paths
See merge request tpo/core/arti!2566
|
| | |
| |
| |
| | |
`upgrade_pending_channel_to_open`
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An attempt to make sure that there are no code paths which forget to
remove a pending channel from the channel map.
This also adds error-level log messages and panics during debug builds
if a `PendingChannelHandle` is dropped without properly passing it to
`MgrState::remove_pending_channel` or
`MgrState::replace_pending_channel`.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit f85bc3cf849109aaa2c4da9fc8c06e7173a0543f.
There were some small conflcits in
`AbstractChanMgr::get_or_launch_internal`, so this wasn't a clean
revert.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
tor-persist: Explain why colons will never be valid slug chars.
See merge request tpo/core/arti!2576
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix various python warnings
See merge request tpo/core/arti!2579
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
As per #1479
|
| | | | |
| | | |
| | | |
| | | | |
As per #1479
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is the first step towards clarifying the questions from !2230.
Corresponding torspec changes: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/282
Part of #1479
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"Black" is an "opinionated" python formatter, whose opinionatedness
is somewhat in the spirit of rustfmt.
This MR runs black with default settings on all of our python code
in Arti. It was produced by the following commands
```
# Everything in python/
black python/
# Everything with a .py extension
fd '.py$' -X black
# Everything with a python shebang.
git grep -l '#! */usr/bin/env *python' | xargs black
```
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit removes the separate function for asking whether to
bypass the dispatch code. Instead, it gives the "invoke with
bypass" function an error to return when no dispatch is warranted,
and moves the whole responsibility for method dispatch or
non-dispatch back into tor-rpcbase.
I had to add an ObjectId argument to `invoke_rpc_method` to make
this work, but that's probably a good thing.
Additionally, this commit tweaks the derive-deftly macro to prevent
you from asking for dispatch bypass on special methods, where it
isn't implemented (and doesn't really make sense).
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Previously we implied that it was only for strings,
which isn't the case.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now, instead of telling the session or the connection to drop the
object ID, we tell the object ID to go away.
Closes #1663.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm about to use this for rpc:release, which is special
because it doesn't actually look at the type of the object that it's
invoked on. Later it might be useful for manipulating weakrefs,
cloning referenes, detecting reference equality, etc.
|
| | | |
| | |
| | |
| | |
| | | |
If and when we implement this, it will likely be different;
arti#868 has some thoughts on the implications.
|
| |/ /
| |
| |
| |
| | |
These will have different implementations soon; this is a more
logical place for them.
|
| | |
| |
| |
| |
| |
| | |
This warning shows up when running `cargo +nightly doc`.
Apparently nightly doesn't like it when we have elided a lifetime
that has a perfectly good name.
|
| | |
| |
| |
| | |
Mark it no longer experimental, but part of full. And document it.
|
| | |
| |
| |
| | |
Mark it no longer experimental, but part of full. And document it.
|