You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We shouldn't ship internal lints to end users. It's just wasted bytes and late passes. There is also the possibility that an internal lint "escapes from the the lab" and causes crashes or bad suggestions. We can put the lints behind a feature flag and only enable it when doing the dogfood test. That would ensure that the lints continue to check Clippy code without making it into a release.
The text was updated successfully, but these errors were encountered:
add `internal-lints` feature to enable clippys internal lints (off by default)
This PR moves the internal lint tests into a new subdirectory (I couldn't find a different way to compile-time-conditionally exclude them from compiletest) and only builds and tests internal lints if the `internal-lints` feature is enabled.
Fixes#6306
changelog: put internal lints behind a feature ("internal-lints")
add `internal-lints` feature to enable clippys internal lints (off by default)
This PR moves the internal lint tests into a new subdirectory (I couldn't find a different way to compile-time-conditionally exclude them from compiletest) and only builds and tests internal lints if the `internal-lints` feature is enabled.
Fixes#6306
changelog: put internal lints behind a feature ("internal-lints")
We shouldn't ship internal lints to end users. It's just wasted bytes and late passes. There is also the possibility that an internal lint "escapes from the the lab" and causes crashes or bad suggestions. We can put the lints behind a feature flag and only enable it when doing the
dogfood
test. That would ensure that the lints continue to check Clippy code without making it into a release.The text was updated successfully, but these errors were encountered: