| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have `Pos::Unknown` for an error at an unknown
location and `Pos::None` for an error where no location is
sensible. There's no reason to have an additional `Option` here.
Additionally, the use of `Option` gave us a bug where our old
`ParseError::at_pos()` method didn't actually set the position
unless the position was already set. That's not what we want!
Fixes #640.
Finally, we have to fix a test that was a bit broken because it was
working around #640.
|
| |
|
|
|
| |
Empty lines were previously reported as BadKeyword, which is
confusing.
|
| |
|
|
|
|
|
|
|
| |
Some of these were for decoding particular objects (we now say
what kind of objects), and some were unrelated tor_cert errors that
for some reason we had shoved into a tor_bytes::Error.
There is now a separate tor_cert::CertError type, independent from
tor_cert's use of `tor_bytes::Error` for parsing errors.
|
| |
|
|
|
| |
The kind type was already public, but we didn't give the user any
way to get it.
|
| |
|
|
| |
It's a little overzealous sometimes, but it's mostly to the good.
|
| |
|
|
|
|
|
| |
The match was doing a deref coercion.
Found by current nightly's needless_match (whose suggestion doesn't
compile, https://github.com/rust-lang/rust-clippy/issues/8551 )
|
| | |
|
| | |
|
| |
|
|
| |
This is a followup for !314 and !310 to fix compilation on main.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This error type doesn't impement HasKind, since the kind will depend
on context.
However, the existing implementation was pretty messy and inconsistent:
Some errors had positions, some didn't.
Some took messages as str, some as String.
Some had internal errors that were somewhat orthogonal to their actual
types.
This commit refactors tor_netdoc::Error to use a ParseErrorKind, and
adds a set of convenience functions to add positions and
messages to the errors that need them.
|
| |
|
|
|
| |
Every other case of tor_netdoc::Error means a parse failure. This one,
though, means a failure to construct a document.
|
| |
|
|
| |
Nothing creates this.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
(The nightly version of clippy now includes macros for its
missing_docs_in_private_items lint.)
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
