Refactor parser methods to not return State as part of ParseError

As previously discovered with #4464, it's easy to accidentally mis-use the State value returned on the Err path.

There were mixed assumptions about what that State represents: (1) the State where the error occurred, or (2) the State at the beginning of the thing we were just parsing.

I fixed this up to always mean (2) - at which point we don't actually need to return the State at all - so it's impossible for further discrepency to creep in.

I also took the liberty to refactor a few more methods to be purely combinator-based, rather than calling `parse` directly.
This commit is contained in:
Joshua Warner 2022-11-15 21:25:51 -05:00
parent 3cd57e078e
commit 2d9aba2242
No known key found for this signature in database
GPG key ID: 89AD497003F93FDD
17 changed files with 374 additions and 456 deletions

View file

@ -20,7 +20,7 @@ pub fn positive_number_literal<'a>() -> impl Parser<'a, NumLiteral<'a>, ENumber>
}
_ => {
// this is not a number at all
Err((Progress::NoProgress, ENumber::End, state))
Err((Progress::NoProgress, ENumber::End))
}
}
}
@ -38,7 +38,7 @@ pub fn number_literal<'a>() -> impl Parser<'a, NumLiteral<'a>, ENumber> {
}
_ => {
// this is not a number at all
Err((Progress::NoProgress, ENumber::End, state))
Err((Progress::NoProgress, ENumber::End))
}
}
}
@ -89,12 +89,12 @@ fn chomp_number_dec<'a>(
if is_negative && chomped == 0 {
// we're probably actually looking at unary negation here
return Err((Progress::NoProgress, ENumber::End, state));
return Err((Progress::NoProgress, ENumber::End));
}
if !bytes.first().copied().unwrap_or_default().is_ascii_digit() {
// we're probably actually looking at unary negation here
return Err((Progress::NoProgress, ENumber::End, state));
return Err((Progress::NoProgress, ENumber::End));
}
let string =