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

Bad parse error on token sequences safe unsafe and unsafe safe (before extern blocks) #133586

Closed
ionicmc-rs opened this issue Nov 28, 2024 · 5 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-edition-2024 Area: The 2024 edition A-parser Area: The parsing of Rust source code to an AST C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ionicmc-rs
Copy link
Contributor

ionicmc-rs commented Nov 28, 2024

Code

safe unsafe extern {
   // Code is irrelevant
}
// And
unsafe safe extern {
   // Code is irrelevant
}

Current output

help: `unsafe` must come before `safe`: `unsafe safe`
# And
help: `safe` must come before `unsafe`: `safe unsafe`

Desired output

# Either an error about how safe isn't stabilized (if it isn't) or something more descriptive
the keyword `safe` is unstable
# ...

Rationale and extra context

the same happens with nightly releases

Other cases

These cases are better mentioned in my newest issue (follow up: #133630)
Note: this is an edit which was made after the pull request

pub unsafe safe extern "C" do_sum(args: (i32, i32)) {
    // ...
}

Ouput:

error: visibility `pub` is not followed by an item
 --> src/err/mod.rs:4:5
  |
4 |     pub unsafe safe extern "C" fn do_sum(args: (i32, i32)) {
  |     ^^^ the visibility
  |
  = help: you likely meant to define an item, e.g., `pub fn foo() {}`

error: expected `{`, found `safe`
 --> src/err/mod.rs:4:16
  |
4 |     pub unsafe safe extern "C" fn do_sum(args: (i32, i32)) {
  |         ------ ^^^^ expected `{`
  |         |
  |         while parsing this `unsafe` expression
  |
help: you might have meant to write this as part of a block
  |
4 |     pub unsafe { safe } extern "C" fn do_sum(args: (i32, i32)) {
  |   

Note: when unsafe and safe are reversed here, it just tells you to reverse it again, but at least this time you aren't in a loop

Rust Version

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

Anything else?

i was just messing around when i found out safe was a valid keyword, but then i got an infinite loop of reversing the order of safe and unsafe

@ionicmc-rs ionicmc-rs added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 28, 2024
@jieyouxu jieyouxu added D-confusing Diagnostics: Confusing error or lint that should be reworked. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. labels Nov 29, 2024
@jieyouxu jieyouxu assigned jieyouxu and unassigned jieyouxu Nov 29, 2024
@jieyouxu jieyouxu added the A-parser Area: The parsing of Rust source code to an AST label Nov 29, 2024
@jieyouxu
Copy link
Member

There's some strange recovery happening to produce this diagnostics.

@jieyouxu
Copy link
Member

jieyouxu commented Dec 7, 2024

Did some investigation in #133618, I feel like parser isn't properly handling safe as a contextual keyword and is conflating its handling with non-contextual keywords like unsafe?

cc @spastorino: does this sound approximately accurate to you? See also the changes in #133618 but that seemed not great either.

@jieyouxu jieyouxu added the C-bug Category: This is a bug. label Dec 7, 2024
@jieyouxu
Copy link
Member

jieyouxu commented Dec 7, 2024

Reproducing @ionicmc-rs's comment in the PR below:


safe isnt supposed to be incompatible with unsafe in this context; safe is not valid in this context

safe unsafe extern {} // safe is only valid inside of this block
// Should give the err: safe is only valid inside of an unsafe extern block

so this error should be for the extern block

unsafe extern {
    unsafe safe fn foo() // Err: safe and unsafe are incompatible
}

this is atleast what i understand
to sum up:

safe /* unsafe */ extern { // err: safe is only valid inside of `unsafe extern` blocks
   // ...
}

unsafe extern {
    safe fn foo() -> i32;
    /* implicit unsafe */ fn bar() -> i32;
    unsafe safe fn x() -> i32; // err: safe and unsafe are incompatible
}
// Now foo can be called safely
println!("{}", foo()); // out: {some number, e.g. 42}
// but not bar
println!("{}", bar()) // err: this operation is unsafe

The desired output:

help: safe is only valid inside of `unsafe extern` blocks

error: safe and unsafe are incompatible # at x
help: if you want to mark this function as safe, remove unsafe

# ...

@jieyouxu
Copy link
Member

jieyouxu commented Dec 7, 2024

cc #133630

@jieyouxu jieyouxu added the A-edition-2024 Area: The 2024 edition label Dec 7, 2024
@fmease fmease changed the title Safe Keyword undescriptive errors Bad parse error on token sequences safe unsafe and unsafe safe (before extern blocks) Dec 20, 2024
@ionicmc-rs
Copy link
Contributor Author

This issue has been combined into one with #133630 at #134580

@ionicmc-rs ionicmc-rs closed this as not planned Won't fix, can't repro, duplicate, stale Dec 20, 2024
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-edition-2024 Area: The 2024 edition A-parser Area: The parsing of Rust source code to an AST C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
2 participants