Diagnostic: Update invalid number suffix error message to match rustc

[nsvke]

Description:

Currently, when an invalid number suffix is provided, gccrs emits a different error message compared to rustc.

Code:

fn main() {
    let _ = 0x1h12;
}

Expected Error Message:

error: invalid suffix `h12` for number literal
  --> <source>:14:13
   |
14 |     let _ = 0x1h12;
   |             ^^^^^^ invalid suffix `h12`
   |
   = help: the suffix must be one of the numeric types (`u32`, `isize`, `f32`, etc.)

error: aborting due to 1 previous error

Compiler returned: 1

Current Error Message:

<source>:14:13: error: unknown number suffix 'h12'
   14 |     let _ = 0x1h12;
      |             ^
Compiler returned: 1 

Possible Fix Location:

Leaving the exact location and steps here in case it helps someone looking for a quick first contribution:

1. The error seems to be emitted in gcc/rust/lex/rust-lex.cc, roughly around lines 1236-1237.
2. Changing the format string in the rust_error_at call from "unknown number suffix %qs" to "invalid suffix %qs for number literal" should fix the core message.
3. A corresponding DejaGnu test in gcc/testsuite/rust/compile/ would also need to be updated or added (e.g., using // { dg-error "invalid suffix .h12. for number literal" }).

Note: Only the error message text needs to match rustc — the output format difference between gccrs and rustc is expected and out of scope.

[powerboat9]

Also, note that suffixes should (you may want to double check) only be verified during parsing into a literal expression -- before then, ~any suffix should be valid

[nsvke]

Following up on your comment, I looked into this further and tested the following code with both rustc and gccrs:

macro_rules! foo { 
    ($x:tt) => {} 
}

fn main() {
    foo!(0x1h12);
}

rustc compiles it successfully because it defers suffix validation. gccrs, however, fails early at the lexer stage, preventing the token from ever reaching the macro expansion. Looking at parse_non_decimal_integer_literal, the lexer evaluates the literal prematurely instead of preserving the raw token string.

​This indicates that the issue goes much deeper than a simple error string mismatch; it reflects a fundamental data loss and behavioral difference. Given this, does it still make sense to keep this issue open for a quick band-aid fix on the error string, or should we re-scope this (or open a new issue) to track the necessary lexer/parser refactor?

[powerboat9]

It's probably best to open a new issue, but keep this one, as they're technically separate