-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Terse parse error on &raw expr
#133231
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
A-parser
Area: The parsing of Rust source code to an AST
A-raw-pointers
Area: raw pointers, MaybeUninit, NonNull
D-terse
Diagnostics: An error or lint that doesn't give enough information about the problem at hand.
F-raw_ref_op
`#![feature(raw_ref_op)]`
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Nov 20, 2024
fmease
added
A-diagnostics
Area: Messages for errors, warnings, and lints
A-parser
Area: The parsing of Rust source code to an AST
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
D-terse
Diagnostics: An error or lint that doesn't give enough information about the problem at hand.
A-raw-pointers
Area: raw pointers, MaybeUninit, NonNull
F-raw_ref_op
`#![feature(raw_ref_op)]`
and removed
C-bug
Category: This is a bug.
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
labels
Nov 20, 2024
The syntax is |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 14, 2024
… r=Noratrieb Add check-pass test for `&raw` `&raw` denotes a normal/non-raw borrow of the path `raw`, not the start of raw borrow since it's not followed by either `const` or `mut`. Ensure this (and variants) will never regress! When I saw the open diagnostic issue rust-lang#133231 (better parse error (recovery) on `&raw <expr>`), it made me think that we have to make sure that we will never commit too early/overzealously(†) when encountering the sequence `&raw`, even during parse error recovery! Modifying the parser to eagerly treat `&raw` as the start of a raw borrow expr only lead to a single UI test failing, namely [tests/ui/enum-discriminant/ptr_niche.rs](https://github.com/rust-lang/rust/blob/4847d6a9d07d4be9ba3196f6ad444af2d7bdde72/tests/ui/enum-discriminant/ptr_niche.rs). However, this is just coincidental — it didn't *intentionally* test this edge case of the grammar. --- †: With "eager" I mean something like: ```patch diff --git a/compiler/rustc_parse/src/parser/expr.rs b/compiler/rustc_parse/src/parser/expr.rs index 0904a42d8a4..68d690fd602 100644 --- a/compiler/rustc_parse/src/parser/expr.rs +++ b/compiler/rustc_parse/src/parser/expr.rs `@@` -873,11 +873,16 `@@` fn error_remove_borrow_lifetime(&self, span: Span, lt_span: Span) { /// Parse `mut?` or `raw [ const | mut ]`. fn parse_borrow_modifiers(&mut self) -> (ast::BorrowKind, ast::Mutability) { - if self.check_keyword(kw::Raw) && self.look_ahead(1, Token::is_mutability) { + if self.eat_keyword(kw::Raw) { // `raw [ const | mut ]`. - let found_raw = self.eat_keyword(kw::Raw); - assert!(found_raw); - let mutability = self.parse_const_or_mut().unwrap(); + let mutability = self.parse_const_or_mut().unwrap_or_else(|| { + let span = self.prev_token.span; + self.dcx().emit_err(ExpectedMutOrConstInRawBorrowExpr { + span, + after_ampersand: span.shrink_to_hi(), + }); + ast::Mutability::Not + }); (ast::BorrowKind::Raw, mutability) } else { // `mut?` ``` --- r? compiler
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 14, 2024
Rollup merge of rust-lang#134274 - fmease:amp-raw-is-a-normal-borrow, r=Noratrieb Add check-pass test for `&raw` `&raw` denotes a normal/non-raw borrow of the path `raw`, not the start of raw borrow since it's not followed by either `const` or `mut`. Ensure this (and variants) will never regress! When I saw the open diagnostic issue rust-lang#133231 (better parse error (recovery) on `&raw <expr>`), it made me think that we have to make sure that we will never commit too early/overzealously(†) when encountering the sequence `&raw`, even during parse error recovery! Modifying the parser to eagerly treat `&raw` as the start of a raw borrow expr only lead to a single UI test failing, namely [tests/ui/enum-discriminant/ptr_niche.rs](https://github.com/rust-lang/rust/blob/4847d6a9d07d4be9ba3196f6ad444af2d7bdde72/tests/ui/enum-discriminant/ptr_niche.rs). However, this is just coincidental — it didn't *intentionally* test this edge case of the grammar. --- †: With "eager" I mean something like: ```patch diff --git a/compiler/rustc_parse/src/parser/expr.rs b/compiler/rustc_parse/src/parser/expr.rs index 0904a42d8a4..68d690fd602 100644 --- a/compiler/rustc_parse/src/parser/expr.rs +++ b/compiler/rustc_parse/src/parser/expr.rs `@@` -873,11 +873,16 `@@` fn error_remove_borrow_lifetime(&self, span: Span, lt_span: Span) { /// Parse `mut?` or `raw [ const | mut ]`. fn parse_borrow_modifiers(&mut self) -> (ast::BorrowKind, ast::Mutability) { - if self.check_keyword(kw::Raw) && self.look_ahead(1, Token::is_mutability) { + if self.eat_keyword(kw::Raw) { // `raw [ const | mut ]`. - let found_raw = self.eat_keyword(kw::Raw); - assert!(found_raw); - let mutability = self.parse_const_or_mut().unwrap(); + let mutability = self.parse_const_or_mut().unwrap_or_else(|| { + let span = self.prev_token.span; + self.dcx().emit_err(ExpectedMutOrConstInRawBorrowExpr { + span, + after_ampersand: span.shrink_to_hi(), + }); + ast::Mutability::Not + }); (ast::BorrowKind::Raw, mutability) } else { // `mut?` ``` --- r? compiler
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Dec 15, 2024
Add check-pass test for `&raw` `&raw` denotes a normal/non-raw borrow of the path `raw`, not the start of raw borrow since it's not followed by either `const` or `mut`. Ensure this (and variants) will never regress! When I saw the open diagnostic issue rust-lang/rust#133231 (better parse error (recovery) on `&raw <expr>`), it made me think that we have to make sure that we will never commit too early/overzealously(†) when encountering the sequence `&raw`, even during parse error recovery! Modifying the parser to eagerly treat `&raw` as the start of a raw borrow expr only lead to a single UI test failing, namely [tests/ui/enum-discriminant/ptr_niche.rs](https://github.com/rust-lang/rust/blob/4847d6a9d07d4be9ba3196f6ad444af2d7bdde72/tests/ui/enum-discriminant/ptr_niche.rs). However, this is just coincidental — it didn't *intentionally* test this edge case of the grammar. --- †: With "eager" I mean something like: ```patch diff --git a/compiler/rustc_parse/src/parser/expr.rs b/compiler/rustc_parse/src/parser/expr.rs index 0904a42d8a4..68d690fd602 100644 --- a/compiler/rustc_parse/src/parser/expr.rs +++ b/compiler/rustc_parse/src/parser/expr.rs `@@` -873,11 +873,16 `@@` fn error_remove_borrow_lifetime(&self, span: Span, lt_span: Span) { /// Parse `mut?` or `raw [ const | mut ]`. fn parse_borrow_modifiers(&mut self) -> (ast::BorrowKind, ast::Mutability) { - if self.check_keyword(kw::Raw) && self.look_ahead(1, Token::is_mutability) { + if self.eat_keyword(kw::Raw) { // `raw [ const | mut ]`. - let found_raw = self.eat_keyword(kw::Raw); - assert!(found_raw); - let mutability = self.parse_const_or_mut().unwrap(); + let mutability = self.parse_const_or_mut().unwrap_or_else(|| { + let span = self.prev_token.span; + self.dcx().emit_err(ExpectedMutOrConstInRawBorrowExpr { + span, + after_ampersand: span.shrink_to_hi(), + }); + ast::Mutability::Not + }); (ast::BorrowKind::Raw, mutability) } else { // `mut?` ``` --- r? compiler
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
A-parser
Area: The parsing of Rust source code to an AST
A-raw-pointers
Area: raw pointers, MaybeUninit, NonNull
D-terse
Diagnostics: An error or lint that doesn't give enough information about the problem at hand.
F-raw_ref_op
`#![feature(raw_ref_op)]`
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
I tried this code:
I expected to see this happen: Code compiles normally
Instead, this happened: A parser error.
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: