Why does Clippy's enum_clike_unportable_variant lint use i32 as a criterion?

community
1

I have a enum:

const ERROR_BIT: usize = usize::MAX - (usize::MAX >> 1);

#[derive(Copy, Clone, Debug, PartialEq, Eq, PartialOrd, Ord, Hash, FromPrimitive)]
#[repr(usize)]
#[allow(clippy::pub_enum_variant_names)]
pub enum Error {
    LoadError = ERROR_BIT | 1,
    // ...
}

Clippy denies the code because it violates enum_clike_unportable_variant:

error: C-like enum variant discriminant is not portable to 32-bit targets
  --> bootloader/stable_uefi/src/result.rs:44:5
   |
44 |     LoadError = ERROR_BIT | 1,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[deny(clippy::enum_clike_unportable_variant)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#enum_clike_unportable_variant

This is not false-positive because ERROR_BIT | 1 doesn't fit into an i32 value on a 64-bit environment. However, the value will not be truncated in a 32-bit environment. ERROR_BIT is 0x8000_0000 on a 32-bit environment and 0x8000_0000_0000_0000 on a 64-bit environment.
I feel this lint is too strict. Why does this lint deny values that don't fit into i32 rather than isize or usize?

2

I believe this is Clippy issue 816. You would still get a warning if that issue is resolved because you derive PartialOrd. The order will be different for i32.

It's a portability lint and some platforms use i32.

3

The value of an eunm discriminant is generally expected to be unchanged and platform-independent. Making it depend on the target pointer size is surprising, in a bad way. It's not about i32 by itself, the lint message doesn't even mention the type i32. The point is that now you are compiling for a 64-bit target, and the code wouldn't be portable to a 32-bit platform. The lint would apply equally well if you were compiling on 32 bit – then it wouldn't be the same on 64 bit, and Clippy could report that "C-like enum variant discriminant is not portable to 64-bit targets". It could just as well report that it wouldn't be portable to 16-bit targets either.

4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.