Hey, I'd like to take a stab at the second point in issue #6623: "Implement framework so that lints can be enabled in nightly only". I have three ideas how this can be implemented, with advantages and drawbacks. Here, I'm hoping to get some early feedback and maybe a few suggestions.

First some background:

• During the compilation with bootstrap, we can determine the targeted release channel with the CFG_RELEASE_CHANNEL environment value. If CFG_RELEASE_CHANNEL is not set, Clippy is most liekly being compiled with Cargo in our respository. Therefore, nightly lints should be enabled. Additionally, we could use UnstableFeatures to determine if unstable features are enabled at runtime.
• In Clippy, we can either use the #[clippy::version] attribute or an additional argument in the declare_clippy_lint macro to indicate is a lint should only be enabled on nightly.
• We need to deal with lint attributes like allow, warn and deny to ensure that they don't trigger the unknown_lints lint when they reference nightly lints while running Clippy stable. This is optional but would be ideal as we otherwise force users to always use nightly.

Now these are the implementation suggestions I have:

1. We add a new Feature to rustc that has to be enabled using a #![feature] attribute to the crate. The nightly lints are only added to the lint store if the feature is enabled, the suppression will be a bit more complicated but should be possible by first checking if the lint is registered.
   • Advantages:
     • Users clearly opt in to Clippys nightly lints
     • Users can use allow, warn and deny attributes with confidence that every user has a nightly Clippy version, since features can only be enabled on nightly versions
   • Disadvantages:
     • We probably get less users testing our nightly lints in comparison to the other options
     • With the feature, users restrict themselves to using nightly.
     • The suppression can't be done at compile time, since features can be enabled and disabled. This makes the emission suppression a bit more expensive in comparison.
     • We would need to enable that feature in all uitests that test nightly lints

2. We register the lints as usual but change the lint level based on the release channel. On stable and beta these lints would be allow-by-default, on nightly they are registered in their corresponding lint groups and with the corresponding lint level.
   • Advantages:
     • Fairly simple to implement, as we reuse rustc's linting infrastructure.
     • Users can switch between stable and nightly as they like, since the lints are also known on stable.
   • Disadvantages
     • Users might unknowingly enable nightly lints on stable.
     • Users don't clearly opt in to nightly lints.

3. We register the lints as usual but suppress the emission for nightly lints based on the release channel in Clippy. I believe this can be fairly easily done by intercepting the lint in our span_lint* methods or later on in span_clippy_lint once Migrate to span_clippy_lint #7797 is implemented.
   • Advantages:
     • Users can switch between stable and nightly as they like, since the lints are also known on stable.
     • Users can't accidentally enable nightly lints on stable.
     • We can implement most of the suppression at compile time
   • Disadvantages
     • Clippy has its own suppression mechanism that has to be maintained, even if it should be simple
     • Users don't clearly opt in to nightly lints.

This list might have missed some options, advantages or disadvantages, feel free to comment on this. I can create mockup implementations for one or two options to compare them 🙃

What are your thought's on this @rust-lang/clippy. Also cc: @Jarcho in case you're interested in this as well 🙃