Terse parse error on &raw expr
#133231
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
A-parser
Area: The lexing & 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
fmease
added
A-diagnostics
|
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 0904a42..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 0904a42..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
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 14, 2025
Rollup merge of rust-lang#139392 - compiler-errors:raw-expr, r=oli-obk Detect and provide suggestion for `&raw EXPR` When emitting an error in the parser, and we detect that the previous token was `raw` and we *could* have consumed `const`/`mut`, suggest that this may have been a mistyped raw ref expr. To do this, we add `const`/`mut` to the expected token set when parsing `&raw` as an expression (which does not affect the "good path" of parsing, for the record). This is kind of a rudimentary error improvement, since it doesn't actually attempt to recover anything, leading to some other knock-on errors b/c we still treat `&raw` as the expression that was parsed... but at least we add the suggestion! I don't think the parser grammar means we can faithfully recover `&raw EXPR` early, i.e. during `parse_expr_borrow`. Fixes rust-lang#133231
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: