| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|
| |
|
|
|
|
|
|
|
| |
This is in lieu of upgrading to the latest base64 crate, which has
a different API from the old one. Since we have to migrate either
way, we might as well use base64ct everywhere.
I don't think that most of these cases _require_ constant-time
base64, but it won't hurt.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceInfo primarily appears in errors, here and in (indirectly)
tor-dirmgr.
This
1. Makes the errors smaller
2. Redacts (currently, scrubs) the chantarget when safe logging is enabled
This commit therefore deals with both tor-dirmgr and tor-dirclient
errors, from the pov of error information that should become sensitive
as part of bridge support.
The error pyaloads directly in tor_dirmgr/src/err.rs don't seem to
contain anything in that category.
|
| | |
|
| |
|
|
| |
These are newly present on 1.65. We can address them later.
|
| | |
|
| |
|
|
|
| |
This is the missing one of the full set. It turns out that I wanted
this rather than the non-consuming output_string.
|
| | |
|
| | |
|
| |
|
|
| |
This gives callers a nice error type with source and everything.
|
| |
|
|
| |
This will be used for bridges' descriptors.
|
| | |
|
| |
|
|
| |
I want this for testing. It seems friendly to provide it, though.
|
| | |
|
| |
|
|
| |
Split off to assist review.
|
| |
|
|
|
|
|
| |
We're going to have functions on Response that fail by returning only
one of these.
Sadly this diff is quite noisy.
|
| |
|
|
|
| |
These don't check errors and are therefore quite hazardous.
I'm going to introduce a more cooked version in a moment.
|
| |
|
|
|
|
|
| |
Apparently cargo fmt doesn't like these, which my perl rune didn't
delete.
This commit is precisely the result of `cargo fmt`.
|
| |
|
|
|
|
|
|
| |
The feature we want is `#[doc = include_str!("README.md")]`, which is
stable since 1.54 and our MSRV is now 1.56.
This commit is precisely the result of the following Perl rune:
perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
|
| | |
|
| |
|
|
|
|
|
| |
These errors no longer use Debug to dump the `Option<SourceInfo>`, but
instead produce reasonable text. Also, I've fixed the SourceInfo
Display implementation so that it now says that it got the error
"from $source via $circuit" rather than the other way around.
|
| |
|
|
|
| |
(It makes sense to use this for things that are not in fact lists of
SHA256 digests of Microdescriptors.)
|
| |
|
|
| |
Update all lint blocks
|
| |
|
|
|
|
|
|
|
| |
According to doc/Errors.md, and in keeping with current best
practices, we should not include display an error's `source()` as
part of that error's display method. Instead, we should let the
caller decide to call source() and display that error in turn.
Part of #323.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
In reviewing !553 I noticed that the empty digest list error had to be
handled in two places. I filed #492 about the duplication.
In fact it turns out to have been quadruplication.
The new code also avoids cloning the underlying objects, instead
sorting a Vec of references.
|
| |
|
|
|
|
| |
I'm not sure this is right. But providing a test case for it before
my next change ensures that my refactoring doesn't change the
behaviour.
|
| |\
| |
| |
| |
| |
| |
| | |
lints: Make lint blocks consistent and ensure they stay that way
Closes #469
See merge request tpo/core/arti!557
|
| | |
| |
| |
| |
| | |
From running add_warning, with manual picking of the right
hunks/lines.
|
| | |
| |
| |
| |
| |
| | |
This was the result of:
maint/add_warning crates/*/src/{lib,main}.rs
and then manually curating the results.
|
| |/ |
|
| | |
|
| |
|
|
| |
(Also, implement Display for tor_dirclient::SourceInfo).
|
| |\
| |
| |
| | |
# Conflicts:
# doc/semver_status.md
|
| | |
| |
| |
| |
| | |
This does involve unwrap, but of course that can't fail unless the
formats fail, which would already panic (that's implied by format!).
|
| |/
|
|
| |
This will help implement #466.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Don't use SystemTime::now()
Closes #306
See merge request tpo/core/arti!365
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit refactors the dirclient error type into two cases:
errors when constructing a circuit, and errors that occur once we
already have a one-hop circuit. The latter can usually be
attributed to the specific cache we're talking to.
This commit also adds a function to expose the information about
which directory gave us the info.
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This is still not as specific as we want; but there's already a TODO
comment in tor-dirclient::err about fixing that at some point in the
future.
|
| |
|
|
|
|
|
| |
Getting a non-200 status is no longer a failure condition; it's just
a different kind of answer.
Closes #349.
|
| | |
|
| | |
|
| | |
|