Skip to content
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

Open
sadmac7000 opened this issue Nov 20, 2024 · 1 comment
Open

Terse parse error on &raw expr #133231

sadmac7000 opened this issue Nov 20, 2024 · 1 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.

Comments

@sadmac7000
Copy link

I tried this code:

mod foo {
    pub static A: i32 = 0;
    pub static B: i32 = 0;
    pub static C: i32 = 0;
}


fn main() {
    let _arr = [ &raw foo::A, &raw foo::B, &raw foo::C ];
}

I expected to see this happen: Code compiles normally

Instead, this happened: A parser error.

error: expected one of `!`, `,`, `.`, `::`, `;`, `?`, `]`, `{`, or an operator, found `foo`
 --> src/main.rs:9:23
  |
9 |     let _arr = [ &raw foo::A, &raw foo::B, &raw foo::C ];
  |                       ^^^ expected one of 9 possible tokens

Meta

rustc --version --verbose:

rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1
@sadmac7000 sadmac7000 added the C-bug Category: This is a bug. label Nov 20, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 20, 2024
@fmease 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
@fmease
Copy link
Member

fmease commented Nov 20, 2024

The syntax is &raw const … / &raw mut …. The error message could be better (raw is a contextual keyword, that's why the parser doesn't give a good~okayish error message out of the box).

@fmease fmease changed the title [&raw foo::BAR] does not parse Terse parse error on &raw expr Nov 20, 2024
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.
Projects
None yet
Development

No branches or pull requests

3 participants