invalid token removal suggested on `unsafe const fn()` type

[cyrgani]

Code

type F = unsafe const fn();

Current output

error: expected one of `extern` or `fn`, found keyword `const`
 --> src/main.rs:1:17
  |
1 | type F = unsafe const fn();
  |          -------^^^^^
  |          |      |
  |          |      expected one of `extern` or `fn`
  |          help: `const` must come before `unsafe`: `const unsafe`
  |
  = note: keyword order for functions declaration is `pub`, `default`, `const`, `async`, `unsafe`, `extern`

error: an `fn` pointer type cannot be `const`
 --> src/main.rs:1:10
  |
1 | type F = unsafe const fn();
  |          ^^^^^^^-----^^^^^
  |                 |
  |                 `const` because of this
  |
help: remove the `const` qualifier
  |
1 - type F = unsafe const fn();
1 + type F = const fn();
  |

Desired output

error: expected one of `extern` or `fn`, found keyword `const`
 --> src/main.rs:1:17
  |
1 | type F = unsafe const fn();
  |          -------^^^^^
  |          |      |
  |          |      expected one of `extern` or `fn`
  |          help: `const` must come before `unsafe`: `const unsafe`
  |
  = note: keyword order for functions declaration is `pub`, `default`, `const`, `async`, `unsafe`, `extern`

error: an `fn` pointer type cannot be `const`
 --> src/main.rs:1:10
  |
1 | type F = unsafe const fn();
  |          ^^^^^^^-----^^^^^
  |                 |
  |                 `const` because of this
  |
help: remove the `const` qualifier
  |
1 - type F = unsafe const fn();
1 + type F = unsafe fn();
  |

Rationale and extra context

The span to remove points at the wrong token.
Happens similarly for extern "C" instead of unsafe.

Other cases

Rust Version

rustc 1.89.0-nightly (6ccd44760 2025-06-08)
binary: rustc
commit-hash: 6ccd4476036edfce364e6271f9e190ec7a2a1ff5
commit-date: 2025-06-08
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

Anything else?

No response

[JonathanBrouwer]

This seems to have been introduced in #133151
The code in that PR incorrectly assumes the qualifiers are in the right order
I think fixing this is a little annoying, we either need to:

• Accept that the suggestion leaves whitespace behind, which mostly reverting the previous PR
• Get the correct span from inside parse_fn_front_matter, which probably means moving the entire check into there. This makes the code of that function a bit more complex, but is probably the better solution

I'll try implementing the second @rustbot claim