`bad_bit_mask` is misguided and the documentation is misleading & unnecessarily combative

[briansmith]

Summary

The documentation says "So the code is actively misleading, and the only reason someone would write this intentionally is to win an underhanded Rust contest or create a test-case for this lint."

There are probably a lot of reasons why one would use such a bit mask. In my case, I have:

#[allow(clippy::assertions_on_constants)]
const _FORCE_DYNAMIC_DETECTION_HONORED: () =
    assert!((CAPS_STATIC & featureflags::FORCE_DYNAMIC_DETECTION) == 0);

When compiling for some platforms, FORCE_DYNAMIC_DETECTION is non-zero, and on other platforms it is zero. In no case (AFAIK) is it wrong. And definitely the code isn't trying to be misleading.

Lint Name

bad_bit_mask

Reproducer

I tried this code:

#[allow(clippy::assertions_on_constants)]
const _FORCE_DYNAMIC_DETECTION_HONORED: () =
    assert!((CAPS_STATIC & featureflags::FORCE_DYNAMIC_DETECTION) == 0);

I saw this happen:

error: &-masking with zero
   --> src/cpu.rs:171:13
    |
171 |     assert!((CAPS_STATIC & featureflags::FORCE_DYNAMIC_DETECTION) == 0);
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#bad_bit_mask
    = note: `#[deny(clippy::bad_bit_mask)]` on by default

I expected to see this happen:
No lint.

Version

Additional Labels

No response

[Centri3]

I assume FORCE_DYNAMIC_DETECTION uses cfg? It's probably best to check for cfg attributes on any constants we see in ConstEvalCtxt as it's not really possible to eliminate this without such a nuclear option.

[briansmith]

I assume FORCE_DYNAMIC_DETECTION uses cfg?

indirectly:

#[cfg(....)]
const FORCE_DYNAMIC_DETECTION = ...;

#[cfg(....)]
const FORCE_DYNAMIC_DETECTION = ...;

#[cfg(....)]
const FORCE_DYNAMIC_DETECTION = 0;