"Forwards compatibility"-breaking lints for const features

What it does

Today I would like to write const fns that use language features such as loops. Due to the limitations in const-context today, these functions have to be written in an unidiomatic way.

Tomorrow, when features like iterators and for loops are available in const-context, I would like clippy to remind me to revisit these functions.

A complex formulation would be a lint that pattern matches the body of const fns looking for evidence that things could be rewritten. (eg, #15046)

A simpler formulation would be a lint that:

• a) is opt-in only
• b) today, never fires
• c) tomorrow, when (eg) iterators/for loops are const, fires blindly without looking at the function body

This means, today I would write:

#[warn(clippy::revisit_const_for, clippy::revisit_const_iter)]
pub const fn bloorp() {
  let mut i = 0;
  while i < 10 { i += 1; ... }
}

Tomorrow, when iterators/for loops are const in the project's MSRV, the lint would start firing and remind me. I would rewrite the function and remove the #[warn].

Advantage

Currently const code that uses loops is very odd-looking, and insidious because it works fine.

Drawbacks

It's a bit weird and unlike other lints(?). There is no possibility of suggestions. It means clippy becomes a TODO app. It probably needs a lint per unstable feature, and the code author to predict which features need stabilization to allow their code to become const.

Example

#[warn(clippy::revisit_const_for, clippy::revisit_const_iter)]
pub const fn bloorp() {
  let mut i = 0;
  while i < 10 { i += 1; ... }
}

When for loops are available in const context, the lint would fire. Now the code would be written as:

pub const fn bloorp() {
  for i in 0..10 { ... }
}

Comparison with existing lints

No response

Additional Context

No response

Start by reviewing how Clippy lints track const-context language features and how stabilized features are represented. The issue names no files, tests, or entry points, so identify those before assessing the proposed opt-in revisit lints. Done means reaching a project decision on whether this design should be implemented and how its feature-specific behavior would be defined.