Lint group for lints slightly below the warn-by-default bar

compiler
1

TLDR: Some allowed-by-default lints are close enough to the warn-by-default bar to be useful in most cases, but don't hit the bar yet to be warn-by-default for all. Users who are willing to pay the downsides of those lints for their benefits would have a better experience using a lint group rather than going through the list of allowed-by-default lints every 6 months to cherry-pick those close to the warn-by-default bar.

Note: This post has been edited, see the history section for explanation.

Motivation for a "warn-by-default staging" lint group

Users who would like to improve their code have a hard time discovering lints. And even worse, say they find a list of allowed-by-default lints they want to enable, they still need active work to keep that list up-to-date as the compiler adds new allowed-by-default lints.

Some users are fine with some level of false positive to improve their code. But they have no way to warn on allowed-by-default lints except by going through each of them one by one, thus going back to the discoverability and maintenability problem.

Even worse, there are lints that are currently allowed-by-default but are intended to be warn-by-default at some point with high probability (e.g. unreachable-pub and unsafe-op-in-unsafe-fn). The main reasons for not being warn-by-default now being that they would trigger on a large amount of existing code, still have some false positives, and/or nobody got the time to do it. Users should have the option to early opt-in those lints, but they can't without going through them one by one, going back to the discoverability and maintenability problem.

If there would be such pedantic lint group, users could easily discover and keep up-to-date with new lints. The workflow would look like this:

  • A user starts a new crate (or wants to improve an existing crate).
  • They add #![warn(pedantic)] to their crate.
  • As they develop (or as a one-time cleanup) and each time a lint triggers, they decide whether they care about that lint. If yes, they fix and improve their code. If no, they add #![allow(no-so-useful-lint-for-this-crate)].
  • As they passively maintain their crate, CI will break (usually on nightly) due to a new lint. The developer will decide whether they care about that lint. If yes, they fix and improve their code. If no, they add #![allow(no-so-useful-lint-for-this-crate)].
  • As they decide to do active maintenance (e.g. once a year), they go through the list of allowed lints at the root of the crate, and decide again if anything changed.

Note that I'm only talking about Rust lints. Clippy lints already solve this issue by providing a partition of their lints in a small number of meaningful groups. And in particular they have a pedantic lint group.

Post history

Original title was "Lint group for allowed-by-default lints that should ideally be warn-by-default". It has initially been modified to "Should we have a pedantic lint group?" to avoid having to decide whether a lint should ideally be warn-by-default or not, since it may be a slow and difficult process. It should be cheap to modify this new lint group because only opt-in users will be impacted, otherwise it defeats its purpose of accelerating uncertain lints providing access to early adopters.

It has later been modified to "Lint group for lints slightly below the warn-by-default bar" to focus on what the lint group should be and whether it's at all useful, punting the naming question for later. For example, those names are not great:

  • "all" or "everything": because the lint group should not contain deprecated lints
  • "pedantic": because it may have a "strictly follow the standard" connotation from C (although clippy doesn't use it in that sense)
5 Likes
2

I think it makes sense to have a group of lints like pedantic, that holds a number of lines that should probably be enabled anyways.

That said, I'm not sure about an all group. There are several lints that are deprecated, irrelevant, or otherwise not applicable for most users. Should those be included in all?

1 Like
3

Good point. If some lints are deprecated or irrelevant, I believe they should not be included in all. This is essentially the symmetrical argument to future-warn-by-default:

  • For future-warn-by-default we want the subset of allowed-by-default lints that are useful but not yet ready to be warn-by-default (either because false positives, or too much legacy code is broken)
  • For all we want to ignore the subset of allowed-by-default lints that are useless but not yet deleted (maybe because nobody got the time to do it), but we still want to include allowed-by-default lints that are not meant to be warn-by-default because they are somehow subjective or circumstantial (they don't apply to all crates). Maybe we could call it possibly-useful-lints (or steal the pedantic keyword from Clippy).
4

I've reformulated the original post to focus on this pedantic lint group. That's the most useful one and it will help keep the discussion focused. I've also removed mentions of future warn-by-default lints to keep the pedantic membership criteria simple. It is important that lints can be easily added to this group if they hit some low bar (much lower than the warn-by-default bar, see this discussion for how the bar can be defined).

5

Generally the philosophy of rustc is that all lints should be at least warn-by-default, or intended to be that. The name "pedantic" says to me "you should be using clippy", not something that should be in rustc itself.

And to some extent I worry about doing this even if it's spelled -Wnursery or something, because right now we're adding lints allow-by-default because they're not good enough yet. So even if they're intended to go warn-by-default soon, that doesn't mean to me that people should necessarily be turning them on now.

And we have -Wnext_release; it's called cargo +beta :upside_down_face:

5 Likes
6

Here is a counterargument: if it was easy to turn on I would give them a try, and see if they found bugs or false positives in my code. I would report such false positives, which could be useful to help improve those lints and make them ready for warn-by-default. That said, I wouldn't turn them on in CI, just try them manually every so often.

But currently it is just too much work doing so. It needs to be low effort. Such as setting a simple RUSTFLAGS in the environment to cargo build (or even an option to cargo build).

2 Likes
7

I think people should be able to decide for themselves. The compiler can only decide for all users, which is why the warn-by-default bar is so high. But if you give users the option, they will be able to set the bar at an appropriate level for them, each one choosing something different.

Clippy already does this for their lints. And Rust also does this for the compiler (users can choose between stable, beta, and nightly depending on the ratio of features to breakage they can tolerate).

1 Like
8

If there are non-deprecated lints that aren't in the group, that group probably shouldn't be called all. The fact that -Wall does not enable all warnings has been irking me for years at this point.

2 Likes
9

clang calls it -Weverything.

10

And gcc has -Wextra. But the fact is that short names like -Wall should be reserved for potentially useful things, and longer names like -Wactually-everything-you-loco can be reserved for people stress testing the linter or whatever else. If -Wall exists people will think it is a reasonable thing to enable, including deprecated or extremely niche or contradictory (these exist!) lints would be unhelpful. Which is all to say -Wpedantic is a better name and crazy options should have names which indicate this.

11

There are already enough people getting tripped up by pedantic clippy lints because -pedantic in C means "no, actually I really want you to follow the standard for real" and is recommended for general use, so people familiar with that ecosystem enable them in Clippy without realizing they aren't default for a reason. I don't think we should copy the naming, whether the categorization is a good idea or not.

For the sake of argument, I like nursery or experimental which convey more the idea that there might be something about these lints that isn't quite complete, so using them is something you should do with caution and not just to make your code better. Maybe false-positives.

1 Like
12

[-pedantic in C is recommended for general use.]

Thanks for pointing that out. I've updated the OP and title to reflect this and punt the naming decision to when we know whether such lint group makes sense and what should be the criteria defining membership to this group.

1 Like
13

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