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

[cyphar]

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

[cyphar]

Ah, it seems this actually only happens with #[open_enum]-tagged enums... I guess this might be an issue with proc-macro enums?