| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This commit adds #[allow(clippy::string_slice)] to all functions in the
code where string slices are used, alongside a TODO comment.
We do this add the function header to have it consistent, as things like
expression based allow's are still experimental.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The NetdocParseableUnverified derive macro implements this
trait (amongst other things). Traits and derive macros should have
aligned names.
This is only used for parsing, so let's keep the "Parseable" part of
the name.
I don't think the effort of deprecated alias, for downstream
compatibility, is worth it, our compatibility policy notwithstanding.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As pointed out in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3985#note_3413185
this was a duplicate.
The new NoFurtherArguments
* Implements encoding
* Implements more traits
* Is in the right module (types::misc - it's not just for parsing)
* Has a slightly better name
* Had an open-coded parsing impl (which we now replace)
* Had minor differences to docs (so we add a line to NoFurtherArguments)
|
| |
|
|
| |
Typos found with codespell
|
| |
|
|
|
|
| |
"Regular" is confusing, especially since in American English it tends
to mean "usual" - whereas, there are no orderly signatures in Tor
netdocs.
|
| |
|
|
|
| |
This could allow users to attach and detach signatures, hash (only)
the body part, etc.
|
| |
|
|
| |
Such an impl is a footgun. Explain this in docs & comments.
|
| |
|
|
| |
(pre-fmt)
|
| |
|
|
|
|
|
|
|
|
| |
During encoding, including these hashes in the signature items makes
no sense. The hashes are an *input* to the signature items, but not
part of them.
Move the hashes out of the items. Instead, provide each signatures
section type with a hash accumulator type, in which the hash(es) are
stored.
|
| | |
|
| |
|
|
| |
This is going to contain body information, and the hashes, too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This was a weird name, and while working in this area it all seemed to
make the docs strange.
Rename it. This is quite invasive!
In theory we could have the macros generate compatibility aliases, but
that seems quite complex.
|
| | |
|
| |
|
|
|
|
|
|
| |
The string so far is exposed already via whole_for_signatures.
It is unusual for a doc parser to need this, but embedded documents
can use this plus byte_position to get the original input text for
their part of the outer document.
|
| | |
|
| | |
|
| |
|
|
| |
There are currently no options.
|
| |
|
|
|
|
|
| |
We're going to add options arguments, effectively, to the parsing
entrypoints. To avoid a proliferation of entrypoints (eg,
parse_multiple_with_options), encapsulate the run-time input values in
this structure.
|
| | |
|
| |
|
|
|
|
|
| |
Provide facilities in ArgumnetStream for determining the column, and
add the field to all the error types up to and including ErrorProblem.
The value still needs to be propagated to ParseError, and printed there.
|
| | |
|
| |
|
|
|
| |
This will allow us to (1) move field name handling out of the argument
parser method, and also (2) add columns more easily.
|
| |
|
|
|
|
|
| |
We're about to have some functions return ArgumentError and some
ErrorProblem. We don't want to provide a conversion directly between
these types, so instead introduce a new type that will be convertible
to either.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This will be useful for impls of ItemValueParseable.
|
| |
|
|
|
| |
The previous code didn't compile at all, and this went unnoticed
because it wasn't used by the poc.
|
|
|
This isn't used anywhere yet. We're going to demonstrate it, and test
the demo, in a moment.
|