| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #338.
|
| |
|
|
|
| |
This patch makes only minimal changes in lower-level error types:
we have more refactoring to do.
|
| |\
| |
| |
| |
| | |
dir-client: bug fix and more tests
See merge request tpo/core/arti!271
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
These bring the case a tiny improvement in test coverage, and also
manage to turn up a few bugs.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
There are a couple of places where we forgot to truncate our
return-buffer to its actual size, and instead returned a big bunch
of zeros. Found while writing the tests in the next commit.
Someday, we'll have ReadBuf and won't have to worry about these
things.
|
| |/
|
|
|
|
| |
Prompted by clippy::needless_question_mark. Sometimes Ok(r?) is
needed to do automatic error conversion. I assume the lint checks for
that. Anyway, in these cases it's not needed.
|
| | |
|
| |
|
|
|
|
|
|
| |
We want to only use TODO in the codebase for non-blockers, and open
tickets for anything that is a bigger blocker than a TODO. These
XXXXs seem like definite non-blockers to me.
Part of arti#231.
|
| | |
|
| |
|
|
| |
Also fix some commonwealth spellings that had slipped in.
|
| |
|
|
| |
Part of #125
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
(The nightly version of clippy now includes macros for its
missing_docs_in_private_items lint.)
|