Skip to content

Clarify longest match behavior of the grammar #1814

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
msprotz opened this issue May 7, 2025 · 2 comments
Open

Clarify longest match behavior of the grammar #1814

msprotz opened this issue May 7, 2025 · 2 comments
Labels
A-grammar Area: Syntax and parsing

Comments

@msprotz
Copy link

msprotz commented May 7, 2025

https://doc.rust-lang.org/reference/expressions.html claims as binds tighter than than + or <

Indeed, with +: let b = 0 as u32 + 0 as u32 parses correctly,

However, with <: let b = 0 as u32 < 0 as u32 gives a syntax error.

I suspect this is due to a conflict in the grammar that looks ahead at the token < and sees the beginning of a type application (in types), but if I'm reading just https://doc.rust-lang.org/reference/expressions.html#r-expr.precedence there's not enough information for me to write a correct Rust syntax printer.

@ehuss
Copy link
Contributor

ehuss commented May 8, 2025

Generally, though it is not fully documented, the productions are greedy in a sense that they will attempt to parse the longest possible set of tokens for a rule (even if that would lead to an error). So, this isn't exactly an operator precedence issue. It is TypePath is greedily taking tokens like < 0 and giving up at some point (probably the as) with an error.

@ehuss ehuss changed the title Incorrect documentation regarding operator precedence (because of a conflict in the grammar) Clarify longest match behavior of the grammar May 8, 2025
@ehuss ehuss added the A-grammar Area: Syntax and parsing label May 8, 2025
@msprotz
Copy link
Author

msprotz commented May 9, 2025

And maybe explain that the grammar won't backtrack (past N tokens, I presume) -- with backtracking one could possibly parse this expression, but it would be expensive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-grammar Area: Syntax and parsing
Projects
None yet
Development

No branches or pull requests

2 participants