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
|
Should we crater this for the macro fragment effects this may theoretically have? Even if just to tell folk that their code needs fixing before this hits stable. |
|
@bors try |
|
@bors ping |
|
😪 I'm awake I'm awake |
Fix parsing of ranges after unary operators Fixes rust-lang#134899. This PR aligns the parsing for unary `!` and `-` and `*` with how unary `&` is already parsed [here](https://github.com/rust-lang/rust/blob/5c0a6e68cfdad859615c2888de76505f13e6f01b/compiler/rustc_parse/src/parser/expr.rs#L848-L854).
compiler-errors
added
I-lang-nominated
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
No one actually relied on this! Great. as errs said, let's ship it once T-lang had a look |
davidtwco
added
S-waiting-on-team
|
cc @ehuss |
|
@rfcbot fcp merge |
|
Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rfcbot
added
proposed-final-comment-period
|
@rfcbot reviewed |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
traviscross
removed
the
I-lang-nominated
|
@rfcbot reviewed OK. For future reference I would appreciate a more thorough comment than the one on this PR, which required a lot of context. I read through the source and finally came to understand what is going. Let me write out what I believe is true..
I don't think it affects When you look at the reference grammar, it just says that |
|
@rfcbot concern +-operator Does this PR intentionally not permit |
rfcbot
added
proposed-final-comment-period
|
@rfcbot resolve +-operator Ah, I think I see why now, because we don't treat |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Fixes #134899.
This PR aligns the parsing for unary
!and-and*with how unary&is already parsed here.