Fix parsing of ranges after unary operators #134900
Conversation
--- stderr -------------------------------
error: expected expression, found `..`
--> tests/ui/parser/ranges-precedence.rs:75:12
|
LL | ($e:expr) => {};
| ------- while parsing argument for this `expr` macro fragment
LL | }
LL | expr!(!..0);
| ^^ expected expression
error: expected expression, found `..`
--> tests/ui/parser/ranges-precedence.rs:76:12
|
LL | ($e:expr) => {};
| ------- while parsing argument for this `expr` macro fragment
...
LL | expr!(-..0);
| ^^ expected expression
error: expected expression, found `..`
--> tests/ui/parser/ranges-precedence.rs:77:12
|
LL | ($e:expr) => {};
| ------- while parsing argument for this `expr` macro fragment
...
LL | expr!(*..0);
| ^^ expected expression
error: aborting due to 3 previous errors
------------------------------------------
rustbot
added
S-waiting-on-review
|
r? parser (this is likely accepting new code or re-accepting code that regressed a while ago) |
There was a problem hiding this comment.
Implementation looks fine and this does align with the approach that the & operator takes. Funny enough that was implemented in #105701, and it never went through an FCP even though it was tagged as such, and obviously changes the set of parsed expressions in a way that makes new guarantees to the grammar (at least effectively? not certain if the grammar in the reference suggests that should be parsed, and I don't really want to look).
I think this is both clearly a T-lang signoff but also trivial and desirable to make, so r=me after that is approved. They also should perhaps retroactively be aware that we began to allow &.. too in 1.68.
compiler-errors
added
T-lang
Fixes #134899.
This PR aligns the parsing for unary
!and-and*with how unary&is already parsed here.