Forbid, deny, warn, allow, and ... notice?

compiler
21

Another potential use-case for notice: usage of some features like specialization come with an obligatory warning that the feature is unstable. This notice should remain, but it would be nice to be able to use --deny warnings in CI.

22

I believe that specifically is a use case #[expect(lint)] is designed for; you say that you expect one occurrence of the incomplete_features lint, and get an error if not exactly one is produced. (And if exactly one is, it's not shown.) I think it's reasonable to say that incomplete_features should be warn by default; it shouldn't block local experimentation, but it definitely should be acknowledged before merging it into a project.

A reviewer shouldn't need to know every feature to catch enabling of an incomplete feature in an otherwise nightly-feature-friendly environment.

23

An #[expect] attribute would have to be placed on the #![feature(..)] attribute, right? Can you even apply attributes to attributes?

Besides which, it really does not solve the problem:

  • Doing so would suppress the "warning: the feature specialization is incomplete and may not be safe to use and/or cause compiler crashes". This warning is supposed to be shown. If it becomes common practice to suppress this with #[expect] or #[allow], then the warning might as well never be shown at all.
  • It makes CI tests harder to configure by requiring code modification. Worse, this configuration is not specific to the CI tests. (In contrast things like #[allow(clippy::type_complexity)] intentionally affect both CI and local testing.)
24

Updates to lints breaking CI when using a rolling toolchain

I think this issue, which is definitely a real problem, is best solved with untangling "language lint version" from the toolchain. I think it would be good to have a config of the "lint version", so I can get all the lints up to 1.73, allowing me to update to 1.74 without any problems. I can then start fixing the new lints and flip the switch once everything is done.

25

I'm not sure this is practical, because we want to be able to fix bugs in lints. I really don't want to say "no, you need to make the behaviour of the lint depend on the version of the lint they were requesting" to people fixing false non-reports in lints.

This is the sibling to "no, the only real way to test your MSRV is to actually use that toolchain" -- trying to look at version annotations won't help. I think that "look, we have a fixed version of rustc in CI that enforces the warnings" is an entirely reasonable way to do that.

3 Likes
26

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.