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

[ionicmc-rs]

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

[jieyouxu]

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

[jieyouxu]

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]

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

# ...