unusual_byte_groupings: ...u64 trailing type is included in grouping calculation

Summary

The unusual_byte_groupings lint appears to treat trailing u64 and similar type casts as being part of the digit grouping, resulting in very unnatural suggestions for better groupings.

EDIT: I only see this for enums with #[open_enum] (a proc macro) so maybe this is actually an issue with proc macro enums?

Lint Name

unusual_byte_groupings

Reproducer

I tried this code:

#![deny(clippy::unusual_byte_groupings)]

use open_enum::open_enum;

#[open_enum]
#[repr(u64)]
#[derive(Debug)]
enum Foo {
    Foobar = 0xFFFF_FFFE_7072_6F63u64,
}

I saw this happen:

error: digits of hex, binary or octal literal not in groups of equal size
 --> src/main.rs:9:14
  |
9 |     Foobar = 0xFFFF_FFFE_7072_6F63u64,
  |              ^^^^^^^^^^^^^^^^^^^^^^^^ help: consider: `0x0FFF_FFFF_E707_26F6_3u64`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unusual_byte_groupings
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(clippy::unusual_byte_groupings)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I expected to see this happen:

No lint warning.

Version

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

Additional Labels

No response

Reproduce the unusual_byte_groupings warning with the provided open_enum proc-macro enum and trailing u64 literal. Start by tracing how the lint handles literals in this enum and compare the result with an equivalent ordinary enum. Done means the valid grouping is no longer reported or rewritten incorrectly, while the lint still catches genuinely uneven groupings.