Umbrella lints

[P1start]

I’ve had a pull request open for quite some time now that adds ‘umbrella lints’, or lint groups, to the compiler. I’m posting this here because this is quite a significant addition to how lints work, and I (and the devs) want some feedback about it, but it’s not really RFC-worthy (probably) and is completely backwards-compatible. (There are some backwards-incompatible changes in my PR but those are largely unrelated.) Basically what this is is a way of having one lint that actually controls multiple lints. For example, my PR adds a built-in bad_style lint group that covers all of the existing style lints. This makes toggling on/off style checks significantly easier—instead of having to explictly #[allow] each and every style lint, one can just use #[allow(bad_style)] to turn off all style-related lints.

If anyone has any suggestions/objections, please let me know! (Particularly, any suggestions for a better name for the bad_style lint group would be appreciated.)

[nikomatsakis]

This seems like a good idea in general but I think we have to be very careful about versioning. Specifically, if a user sets their code to forbid(bad_style), then adding new style lints becomes a breaking change, and hence would to be limited to major releases (per semantic versioning). This has certainly been a problem that prevents people from using -Wall and -Werror with gcc. (Note that this is not a problem without style groups: we can always add new lints so long as the default setting is not error.) It might be that the answer is just to incorporate some kind of rustc version number into the style group names.

[reem]

My gut feeling is that by opting to turn style-related warnings into failures through an an explicit #[deny(bad_style)] you are opting into failing builds as a result of style changes.

[P1start]

@nikomatsakis That’s a good point, but I don’t consider it too much of a problem with lint groups exclusively because it’s also a problem (in a slightly different sense) with normal lints—if a lint is modified to be stricter, any code with that lint set to deny or forbid will stop working if there’s something that triggers the lint under the updated rules but not with the previous version of the lint. Making lints stricter is backwards-incompatible, and in the same way making lint groups stricter (i.e., adding more lints) is backwards-incompatible.

That said, I would assume that it’s more common to add lints than modify them in a backwards-incompatible fashion, which means that breaking lint groups could be more common than breaking normal lints.

[system]

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