lucretiel / nom-supreme Goto Github PK

Otherwise, it's pretty hard to use assert_eq! with the latest stable compiler.

assert_eq!(tag("input"), Ok(("", "input")));

I'm currently trying to get nom-supreme and miette working together. To do so, I need to transform a ErrorTree into a useable miette::Diagnostic.

Now, my problem is how do I pass on information nicely on 'why' it didn't work. For that, I was thinking of using .context, but that is stringly typed. Now, I can definitely use it (and use some parse/constants) to make it easier to use but is that the intended way?

It should be possible to include the parsed terminator in the multi parsers. This is not likely to be a common requirement, so I'm not sure yet how to do it- more parser functions? Output trait? Unconditionally include it anyway? Combinator that turns (A, B) into A?

you don't have a discussion board but I'd like to tell you that I think this crate is very much beautiful.

Thank you

Hi,
Since there's no discussion board, this seemed like the only way to broach the subject. I've read about this crate on reddit and it sounded like it would be useful for me but I can't seem to figure out how exactly to use it.

I used nom to parse expression of this kind: id 23 or name cu and not sphere 2589 6
Basically I wrote a separate function for each piece and built them up.
It all works like it should but since this is for a CLI tool I need decent error messages. Something like the column where an error occurred and some useful context (not quite sure yet what exactly that should be).
For now I used final_parser on my top-level nom parser which in turn contains an ErrorTree. The resulting error messages look something like this:

in section "listparse" at line 1, column 1,
one of:
  in section "sphere" at line 1, column 1,
  one of:
    error in Tag at line 1, column 1, or
    error in Tag at line 1, column 1, or
    error in Tag at line 1, column 1, or
    error in Tag at line 1, column 1, or
  in section "ids" at line 1, column 1,
  in section "single ID element" at line 1, column 4,
  in section "id" at line 1, column 4,
  one of:
    in section "range" at line 1, column 4,
    expected an ascii digit at line 1, column 4, or
    expected an ascii digit at line 1, column 4, or
  in section "strlist" at line 1, column 1,
  one of:
    error in Tag at line 1, column 1, or
    error in Tag at line 1, column 1, or
    error in Tag at line 1, column **1**

I didn't attach a context to every single parser, I think that's why this looks a bit inconsistent. It looks like this is the full error tree, is there a way to display only the error for the parser that actually failed? I mean, this shows a number of possibilities of what could have gone wrong but doesn't show what actually did go wrong.
Also is there a way to extract the column information from the error in some way? I'd like to process it further.
Sorry if these questions are stupid but I'm new to parsing like this and I have trouble wrapping my head around it all.

Hi!

Is there any chance we could get this crate for no_std usecases? From what I see, only joinery and brownstone do not have a std feature! memchr, nom and indent_write have one that could be turned off!

I am not sure whether the functionality introduced by either joinery or brownstone can simply be excluded for the no_std case (did not look that closely yet), but if you're interested, I'd have a closer look and am willing to come up with a PR if I can manage! 😉

Related: TheNeikos/cloudmqtt#24

nom-supreme is starting to get somewhat popular, so we should have a README on the main github page.

Hi, first of all, thank you for making such a great library! I just wanted to talk about a minor inconvinence I've encounter, I wonder whether is there any way to resolve it.

In the following code, I have a generic nom parser. I wanted to use the function final_parser on it, but it doesn't compile.

use nom::{character::complete::alpha1, IResult, Parser};
use nom_supreme::final_parser::final_parser;

fn parser(input: &str) -> IResult<&str, String> {
    Ok(alpha1.map(String::from).parse(input)?)
}

fn main() {
    let s = "str";
    let parsed = final_parser(parser)(s).unwrap();
                          ^^^^^^^^^^^^ - cannot infer type for type parameter `E2` declared on the function `final_parser`
    println!("{}", parsed);
}

It would be ideal for final_parser to infer the errors, just like one can work with nom IResult type without saying error types explicitly.

map is useful to replace map_res where the closure doesn't return a Result.

I am parsing a binary protocol, so I have some binary tags to match. But TagError is only implemented for &'static str tags for ErrorTree, so I can't use ErrorTree as my error type.

Minimal example:

fn parse_tag(input: &[u8]) -> IResult<&[u8], &[u8], ErrorTree<&[u8]>> {
    tag(b"\x00").parse(input)
}

Error:

rror[E0277]: the trait bound `ErrorTree<&[u8]>: TagError<&[u8], &[u8; 1]>` is not satisfied
  --> test/src/main.rs:10:5
   |
66 |     tag(b"\x00").parse(input)
   |     ^^^ the trait `TagError<&[u8], &[u8; 1]>` is not implemented for `ErrorTree<&[u8]>`
   |
   = help: the following implementations were found:
             <ErrorTree<I> as TagError<I, &'static str>>
note: required by a bound in `nom_supreme::tag::complete::tag`
  --> /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/nom-supreme-0.6.0/src/tag.rs:95:12
   |
95 |         E: TagError<I, T>,
   |            ^^^^^^^^^^^^^^ required by this bound in `nom_supreme::tag::complete::tag`

Propose adding to ParserExt:

/// Parse a fixed size array by calling this parser a fixed number of times
fn array<const N: usize>(self) 

/// Same as above, but also parse a separator between each element
fn separated_array<const N: usize>(self, separator)

Currently docs.rs is not compiling the docs with the feature error on. Which is because docs.rs only builds default features per-default.

This can be changed through metadata in the Cargo.toml file: https://docs.rs/about/metadata

I think this would be a worthwhile addition as this way one can see the ErrorTree docs without having to build it yourself.