Fix parsing of ranges after unary operators #134900

dtolnay · 2024-12-29T19:09:42Z

This PR aligns the parsing for unary ! and - and * with how unary & is already parsed here.

--- 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 · 2024-12-29T19:09:50Z

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

tests/ui/parser/ranges-precedence.rs

jieyouxu · 2024-12-30T10:58:32Z

r? parser (this is likely accepting new code or re-accepting code that regressed a while ago)

compiler-errors

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.

oli-obk · 2025-02-05T19:25:42Z

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.

dtolnay · 2025-02-05T23:49:32Z

@bors try

dtolnay · 2025-02-05T23:58:48Z

@bors ping

bors · 2025-02-05T23:58:51Z

😪 I'm awake I'm awake

bors · 2025-02-06T00:00:13Z

⌛ Trying commit 462604d with merge 64628e5...

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).

bors · 2025-02-06T01:49:41Z

☀️ Try build successful - checks-actions
Build commit: 64628e5 (64628e57ec7d61fad21c958209d4b2ee40a934d1)

rfcbot · 2025-02-19T16:51:48Z

🔔 This is now entering its final comment period, as per the review above. 🔔

nikomatsakis · 2025-02-19T16:55:41Z

@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..

In the past, unary operators like ! and - did not accept ..X range expressions. In the code, this comes out from the fact that they invoke parse_expr_prefix which, for reasons I do not know but I presume has to do with precedence, does not accept ranges. This PR changes them to basically accept both prefixes. It should affect the following operators from my read of the code: !, ~, -, *.

I don't think it affects +.

When you look at the reference grammar, it just says that ! and friends are followed by an Expression, which could be a range expression, so this feels like a bug fix from that perspective.

nikomatsakis · 2025-02-19T16:56:44Z

@rfcbot concern +-operator

Does this PR intentionally not permit +..5 to parse as an expression? From my read of the code, it does not cover this case, but why?

nikomatsakis · 2025-02-19T16:57:34Z

@rfcbot resolve +-operator

Ah, I think I see why now, because we don't treat + as an operator, we just special case the +-literal. I'm gonna resolve my concern for now.

rfcbot · 2025-02-19T16:57:45Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2025-03-01T17:01:18Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

dtolnay · 2025-03-01T18:36:12Z

@bors r=compiler-errors,davidtwco
compiler-errors: #134900 (review)
davidtwco: #134900 (review)

bors · 2025-03-01T18:36:15Z

📌 Commit 462604d has been approved by compiler-errors,davidtwco

It is now in the queue for this repository.

…rs,davidtwco 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).

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#132388 (Implement `#[cfg]` in `where` clauses) - rust-lang#134900 (Fix parsing of ranges after unary operators) - rust-lang#136938 (Remove `:` from `stack-protector-heuristics-effect.rs` Filecheck Pattern) - rust-lang#137054 (Make phantom variance markers transparent) - rust-lang#137525 (Simplify parallelization in test-float-parse) - rust-lang#137618 (Skip `tidy` in pre-push hook if the user is deleting a remote branch) - rust-lang#137685 (self-contained linker: conservatively default to `-znostart-stop-gc`) - rust-lang#137741 (Stop using `hash_raw_entry` in `CodegenCx::const_str`) - rust-lang#137849 (Revert "Remove Win SDK 10.0.26100.0 from CI") - rust-lang#137862 (ensure we always print all --print options in help) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#132388 (Implement `#[cfg]` in `where` clauses) - rust-lang#134900 (Fix parsing of ranges after unary operators) - rust-lang#136938 (Remove `:` from `stack-protector-heuristics-effect.rs` Filecheck Pattern) - rust-lang#137054 (Make phantom variance markers transparent) - rust-lang#137525 (Simplify parallelization in test-float-parse) - rust-lang#137618 (Skip `tidy` in pre-push hook if the user is deleting a remote branch) - rust-lang#137741 (Stop using `hash_raw_entry` in `CodegenCx::const_str`) - rust-lang#137849 (Revert "Remove Win SDK 10.0.26100.0 from CI") - rust-lang#137862 (ensure we always print all --print options in help) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#134900 - dtolnay:unoprange, r=compiler-errors,davidtwco 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).

dtolnay added 2 commits December 29, 2024 11:03

Fix parsing of ranges after unary operators

462604d

rustbot assigned lcnr Dec 29, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 29, 2024

dtolnay added the A-parser Area: The parsing of Rust source code to an AST label Dec 29, 2024

jieyouxu reviewed Dec 29, 2024

View reviewed changes

tests/ui/parser/ranges-precedence.rs Show resolved Hide resolved

rustbot assigned davidtwco and unassigned lcnr Dec 30, 2024

compiler-errors approved these changes Dec 30, 2024

View reviewed changes

ehuss mentioned this pull request Dec 31, 2024

Ensure all precedence rules are covered. rust-lang/reference#577

Open

traviscross removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Feb 19, 2025

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Feb 19, 2025

rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Feb 19, 2025

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Mar 1, 2025

rustbot mentioned this pull request Mar 1, 2025

Tracking issue for release notes of #134900: Fix parsing of ranges after unary operators #137859

Open

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Mar 1, 2025

matthiaskrgr mentioned this pull request Mar 3, 2025

Rollup of 10 pull requests #137918

Closed

matthiaskrgr mentioned this pull request Mar 3, 2025

Rollup of 9 pull requests #137927

Merged

bors merged commit 9aff9c0 into rust-lang:master Mar 4, 2025
7 checks passed

rustbot added this to the 1.87.0 milestone Mar 4, 2025

dtolnay deleted the unoprange branch March 4, 2025 02:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix parsing of ranges after unary operators #134900

Fix parsing of ranges after unary operators #134900

dtolnay commented Dec 29, 2024

rustbot commented Dec 29, 2024

jieyouxu commented Dec 30, 2024

compiler-errors left a comment •

edited

Loading

oli-obk commented Feb 5, 2025

dtolnay commented Feb 5, 2025

dtolnay commented Feb 5, 2025

bors commented Feb 5, 2025

bors commented Feb 6, 2025

bors commented Feb 6, 2025

rfcbot commented Feb 19, 2025

nikomatsakis commented Feb 19, 2025

nikomatsakis commented Feb 19, 2025

nikomatsakis commented Feb 19, 2025 •

edited

Loading

rfcbot commented Feb 19, 2025

rfcbot commented Mar 1, 2025

dtolnay commented Mar 1, 2025

bors commented Mar 1, 2025

Fix parsing of ranges after unary operators #134900

Fix parsing of ranges after unary operators #134900

Conversation

dtolnay commented Dec 29, 2024

rustbot commented Dec 29, 2024

jieyouxu commented Dec 30, 2024

compiler-errors left a comment • edited Loading

Choose a reason for hiding this comment

oli-obk commented Feb 5, 2025

dtolnay commented Feb 5, 2025

dtolnay commented Feb 5, 2025

bors commented Feb 5, 2025

bors commented Feb 6, 2025

bors commented Feb 6, 2025

rfcbot commented Feb 19, 2025

nikomatsakis commented Feb 19, 2025

nikomatsakis commented Feb 19, 2025

nikomatsakis commented Feb 19, 2025 • edited Loading

rfcbot commented Feb 19, 2025

rfcbot commented Mar 1, 2025

dtolnay commented Mar 1, 2025

bors commented Mar 1, 2025

compiler-errors left a comment •

edited

Loading

nikomatsakis commented Feb 19, 2025 •

edited

Loading