mirrors/arti.git/crates/tor-netdoc/src/parse/parser.rs, branch arti-v1.4.2

netdoc: Make some parsing init functions fallible.

2025-03-17T16:55:57Z

I'm about to make our parsers reject some strings at construction time, so it makes sense to have these functions become fallible. This is a breaking change.

Run maint/add_warning.

2024-03-13T16:30:53Z

clippy: Replace many calls to .get(0) with .first()

2024-01-02T13:56:08Z

FTR I don't think agree with clippy on this question, but then I often don't.

Run maint/add_warning to add lint block everywhere

2023-08-23T09:34:00Z

Run maint/add_warning to actually apply new lint allows

2023-07-10T12:49:51Z

netdoc: Rename parse_error_kind() to netdoc_error_kind().

2023-05-11T17:39:40Z

`ParseErrorKind` was renamed to `NetdocErrorKind`, so we need to rename this acccessor too. Signed-off-by: Gabriela Moldovan

netdoc: Rename `ParseError{Kind, Source}` to `NetdocError{Kind, Source}`.

2023-05-10T14:52:28Z

`ParseErrorSource` was originally meant to represent a parsing error, this enum has since gained some variants that aren't really parsing related (`Signature`, `CertSignature`, `UntimelyDescriptor`). Since this error type is now used for general-purpose netdoc errors, let's rename `ParseError{Kind, Source}` to `NetdocError{Kind, Source}`. Signed-off-by: Gabriela Moldovan

tor-netdoc: Remove many needless calls to .iter() and .into_iter()

2023-02-15T17:17:01Z

tor-netdoc: Have sectionrules.parse take I, not &mut I

2023-02-15T17:16:57Z

There's a blanket impl of Itertor for &mut impl Iterator, so this isn't necessary, and it prevents us passing iterators by value producing syntactic vinegar.

netdoc: Require that unrecognized tokens be handled explicitly.

2023-02-03T16:33:30Z

Now we require that, for all `SectionRules`, either the caller say how to handle unrecognized tokens (using `.add(UNRECOGNIZED...)`), or that they explicitly reject unrecognized tokens (using `reject_unrecognized`()`.) This solution uses an assert!() rather than an Error to indicate failure. I say that's fine, since 1. This is a crate-internal API. 2. We never dynamically construct SectionRules according to different behavior: they are always prefabricated in a fixed code block. Thus, if we test a parser at all, we will make sure that its SectionRules are well-formed. I considered and explicitly rejected a solution where the builder had to be finalized with separate methods `build_strict()` or `build_tolerant()`: It's too easy IMO for the caller to forget what these call means. Prevents further recurrences of #752. Closes #752.