How to test code with Located als input?

[TheNeikos]

I am currently writing a simple parser and wanted to use Located as its input. An issue arises when I want to test the parse.

use std::ops::Range;

use winnow::{
    bytes::one_of, combinator::opt, multi::many1, sequence::preceded, IResult, Located, Parser,
};

#[derive(Debug, Clone, PartialEq)]
struct Number {
    value: i64,
    span: Range<usize>,
}

fn parse_number(input: Located<&str>) -> IResult<Located<&str>, Number> {
    let sign = opt('-');
    let digits = many1::<_, _, (), _, _>(one_of("0123456789"))
        .recognize()
        .map_res(|digits: &str| digits.parse::<i64>());
    let number = (sign, digits);

    number
        .with_span()
        .map(|((sign, digits), span): ((Option<char>, i64), _)| {
            let is_negative = sign.map(|_| -1).unwrap_or(1);

            Number {
                value: digits * is_negative,
                span,
            }
        })
        .parse_next(input)
}

#[cfg(test)]
mod tests {

    use winnow::Located;

    use crate::parser::number::{parse_number, Number};

    #[test]
    fn simple_numbers() {
        let input = Located::new("123");

        assert_eq!(
            parse_number(input),
            Ok((
                input,
                Number {
                    value: 123,
                    span: 0..3
                }
            ))
        );
    }
}

I can only construct Located with ::new, and there is no way to advance the internal input. Is there some API I overlooked, or is this simply not the intended way?

[epage]

Yes, this was an annoying part for some of the examples.

In the short term, you could either

• Not verify input, just the output
• Use input.next_slice(3).0

In the medium term, we'll likely be tweaking the parser interface in #72 which will make it so you pass in &mut input and input is not returned. Granted, you still might want to verify the state of input but it will at least be in a separate call rather than making one complex assert.

One idea I just had is if we make all of the input wrappers implement PartialEq / Eq for the inner input. Except Result only implements PartialEq when the two sides T is the same type and rather than for anything comparable to T, so this won't work.

So the only thing I can think of is if we implemented Index for RangeTo so you could do input[3..]. The main question is if this is enough of an advantage over input.next_slice(3).0. Thoughts?

[TheNeikos]

I have to admit, I wouldn't know of any consequences of either approaches haha.

I don't think I would mind doing two different checks/asserts for remainder + output.

I'll try to use next_slice in the short term, and then adapt to the new interface.