| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
Now the network fallbacks configuration wants to Deserialize
a Vec<FallbackDirBuilder>, rather than validated Vec<FallbackDir>.
Methods on FallbackListBuilder are as per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/462#note_2797697
mutatis mutandi for the fact that this struct has only fallbacks in it.
|
| | |
|
| |
|
|
| |
Fixes #314, #418.
|
| | |
|
| | |
|
| |
|
|
| |
Code motion and import fixups.
|
| |
|
|
|
| |
Making these fields pub(crate) is quite reasonable and does away with
the need for accessors.
|
| |
|
|
|
|
|
| |
We put this in cfg.rs, rather than (say) socks.rs, because it has
config relating to both socks.rs and dns.rs.
Code motion and import fixups.
|
| |
|
|
| |
This was clumsy. Now it is brought together it can be simplified.
|
| |
|
|
|
|
|
| |
This de-duplicates the code that was in those accessors, and is now in
filt_from_opt_str.
Code motion and direct field access.
|
| |
|
|
|
|
| |
There are no longer needed, because the code that uses this
configuration now lives in the same module as the configuration
itself.
|
| |
|
|
| |
Code motion and import fixups.
|
| |
|
|
|
| |
We are going to move LoggingConfig here. We should follow the
already-public name IMO.
|
| |
|
|
| |
Code motion and import fixups.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of requiring a `Box<dyn Isolation>`, it now takes either a
`Box<dyn Isolation>`, or an arbitrary `T` that implements
`Isolation`.
This API still allows the user to pass in a `Box<dyn Isolation>` if
that's what they have, but it doesn't require them to Box the
isolation on their own.
Part of #414.
|
| |\
| |
| |
| |
| | |
new api for isolation
See merge request tpo/core/arti!377
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
it seems I added conditional compilation without noticing it??
and there was some errors when choosing a prefered runtime depending on
feature flags
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I ought to have c&p these.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/403#note_2786099
|
| | |
|
| |
|
|
|
| |
This does not constitute any kind of stable API promise.
But it might allow people to use our arti client code in novel ways.
|
| | |
|
| |
|
|
| |
This is just code motion and the minimal fixups.
|
| | |
|
| |\
| |
| |
| |
| | |
Disable clippy::clone_on_ref_ptr
See merge request tpo/core/arti!352
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This lint is IMO inherently ill-conceived.
I have looked for the reasons why this might be thought to be a good
idea and there were basically two (and they are sort of contradictory):
I. "Calling ‘.clone()` on an Rc, Arc, or Weak can obscure the fact
that only the pointer is being cloned, not the underlying data."
This is the wording from
https://rust-lang.github.io/rust-clippy/v0.0.212/#clone_on_ref_ptr
It is a bit terse; we are left to infer why it is a bad idea to
obscure this fact. It seems to me that if it is bad to obscure some
fact, that must be because the fact is a hazard. But why would it be
a hazard to not copy the underlying data ?
In other languages, faliing to copy the underlying data is a serious
correctness hazard. There is a whose class of bugs where things were
not copied, and then mutated and/or reused in multiple places in ways
that were not what the programmer intended. In my experience, this is
a very common bug when writing Python and Javascript. I'm told it's
common in golang too.
But in Rust this bug is much much harder to write. The data inside an
Arc is immutable. To have this bug you'd have use interior mutability
- ie mess around with Mutex or RefCell. That provides a good barrier
to these kind of accidents.
II. "The reason for writing Rc::clone and Arc::clone [is] to make it
clear that only the pointer is being cloned, as opposed to the
underlying data. The former is always fast, while the latter can
be very expensive depending on what is being cloned."
This is the reasoning found here
https://github.com/rust-lang/rust-clippy/issues/2048
This is saying that *not* using Arc::clone is hazardous.
Specifically, that a deep clone is a performance hazard.
But for this argument, the lint is precisely backwards. It's linting
the "good" case and asking for it to be written in a more explicit
way; while the supposedly bad case can be written conveniently.
Also, many objects (in our codebase, and in all the libraries we use)
that are Clone are in fact simply handles. They contain Arc(s) (or
similar) and are cheap to clone. Indeed, that is the usual case.
It does not make sense to distinguish in the syntax we use to clone
such a handle, whether the handle is a transparent Arc, or an opaque
struct containing one or more other handles.
Forcing Arc::clone to be written as such makes for code churn when a
type is changed from Arc<Something> to Something: Clone, or vice
versa.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed conflict in crates/arti-client/src/lib.rs as per tree
from
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/364/#note_2782166
ie 13e55b8d7c22c26e55ba75823409b477f1bce66b
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Otherwise, it's impossible to get a static sqlite linkage without
also getting native-tls, even if you wanted rustls.
Closes #302.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes using the `PreferredRuntime` the first-class option inside
`arti-client`, freeing users who don't want to think about runtimes from
having to do so.
`TorClient::create_unbootstrapped` and `builder` now automatically
use this runtime, leaving only `builder_custom` for users who wish to
manually specify a runtime.
This lets us clean up the docs a lot: mentions of using custom runtimes
are now relegated to nearer the end of the crate-level documentation,
and we mostly just link to `tor_rtcompat`'s docs to explain more there.
Instead, we take some more time to explain how you use the builder API
to create clients synchronously.
Other doc cleanups included getting rid of the explanation of `TorAddr`
in the main crate-level doc; this is already well-documented elsewhere,
and is something users should discover organically later.
fixes arti#326
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
make arti return a web page when receiving http request on socks port
See merge request tpo/core/arti!348
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Make a TorClientBuilder API.
Closes #350
See merge request tpo/core/arti!337
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This is a defensive API choice to protect against the possibility
that we'll want to add a bunch of other non-config options in
the future.
Closes #350
|
| |\ \
| |/
|/|
| |
| | |
Improve error messages from arti cli
See merge request tpo/core/arti!331
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|