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

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

Start by locating the bad_bit_mask lint implementation and its documentation using the lint name, then run the provided Rust reproducer. Determine how platform-dependent constant masks are handled and review the diagnostic wording. Done means the valid use case is no longer incorrectly linted and the documentation accurately describes the lint without the disputed claim.