Forbids use of `core::ops::RangeInclusive` in constants and statics.

What it does

Forbids using core::ops::RangeInclusive in consts and (non-mutable) statics.

It would be nice if this could detect usage in struct fields (at for structs defined in the same crate), i.e.

Advantage

It's not too rare to work with static lists of inclusive ranges of... stuff. For example, this is especially common in unicode data, where they're often ranges of either char, or sometimes numeric types.

core::ops::RangeInclusive may seem natural for this, however it stores an extra field of exhausted: bool for the Iterator implementation which causes each range to be larger by at least one byte (almost always more than one, due to padding), increasing binary size and memory usage for no benefit (the relevant Iterator methods cannot be used on consts/statics).

Drawbacks

Some people don't care about such things, and it's mostly a problem when you have many of them.

(I don't care to argue that it should be on by default, a restriction/pedantic lint would be fine by me, even if it is pretty much always bad)

Example

const RANGES: &[RangeInclusive<char>] = &[
    '\u{0}'..='\u{7f}',
    '\u{80}'..='\u{7ff}',
    '\u{800}'..='\u{ffff}',
    '\u{10000}'..=char::MAX,
];

Could be written as:

const RANGES: &[(char, char)] = &[
    ('\u{0}', '\u{7f}'),
    ('\u{80}', '\u{7ff}'),
    ('\u{800}', '\u{ffff}'),
    ('\u{10000}', char::MAX),
];

No source files, tests, or entry points are named. Start by locating Clippy's existing lint implementations for const and static analysis, then define how the requested restriction and same-crate struct-field detection should be covered. Done means the intended RangeInclusive cases are diagnosed with tests while allowed cases remain unaffected.