Pratt parser

[lu-zero]

Rebase of #614
Closes #131

I guess porting what we have in #620 could happen later or within this PR.

[github-advanced-security]

clippy found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[coveralls]

Pull Request Test Coverage Report for Build 16239183961

Details

• 61 of 97 (62.89%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.8%) to 47.428%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/combinator/expression.rs	61	97	62.89%

Totals
Change from base Build 16221869183:	0.8%
Covered Lines:	1669
Relevant Lines:	3519

---

💛 - Coveralls

[epage]

Could you clean up the commit history, per our CONTRIBUTING.md?

[epage]

We should include the example from #622

[epage]

I'd probably name that c_expr, rather than pratt. Trying to decide how it should show up in our docs, maybe a sub-page if Languages but have Arithmetic cross-link to it?

[ssmendon]

We should include the example from #622

I'm on vacation and haven't had much time to look at this code, but I started porting the example to the new API. If it helps: https://github.com/ssmendon/winnow/blob/devel-pratt/examples/pratt/parser.rs#L72-L163

All commits: https://github.com/ssmendon/winnow/commits/devel-pratt

Some notes:

• Needed to make Prefix's fields public to use the API in ssmendon@1d5454e

[epage]

CC @39555

[lu-zero]

Probably we could drop current_.

[lu-zero]

shall we pub use the main function in the parent module as the rest of the functions?

[codecov]

Codecov Report

❌ Patch coverage is 62.88660% with 36 lines in your changes missing coverage. Please review.
✅ Project coverage is 47.42%. Comparing base (18f20ee) to head (f878de8).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/combinator/expression.rs	62.88%	36 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #798      +/-   ##
==========================================
+ Coverage   46.72%   47.42%   +0.70%     
==========================================
  Files          26       27       +1     
  Lines        3416     3519     +103     
==========================================
+ Hits         1596     1669      +73     
- Misses       1820     1850      +30     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ssmendon]

Question for @39555.

I think you meant to implement this for Postfix instead of for the tuple? Like this:

impl<I: Stream, O, E: ParserError<I>> Parser<I, Postfix<I, O, E>, E> for Postfix<I, O, E> {
    #[inline(always)]
    fn parse_next(&mut self, input: &mut I) -> Result<Postfix<I, O, E>, E> {
        empty.value(self.clone()).parse_next(input)
    }
}

I noticed this while porting the example in #622 to my own fork: https://github.com/ssmendon/winnow/blob/pratt-parsing/examples/c_expression/parser.rs

Specifically, I noticed this syntax doesn't work due to unsatisfied trait bounds:

dispatch! {take(2usize);
    "++" => Postfix(20, |_: &mut _, a| Ok(Expr::PostIncr(Box::new(a)))),
    "--" => Postfix(20, |_: &mut _, a| Ok(Expr::PostDecr(Box::new(a)))),
    _ => fail,
},

Notes:

• You can't implement the original trait outside of winnow due to trait orphan rules.
• The example inside of crate::combinator::expression doesn't use any Postfix rules, but it is in the example (e.g. cargo test -F unstable-doc,std --all).

[ssmendon]

I added my own PR in #804, which tries to address some of the review comments attached to this. I did not really look at the code in this PR, so I don't know in what ways our implementation is different (if at all).

[lu-zero]

Let me close this in favor of #804 then.