feat: add cfg_not_test lint

[mrnossiom]

Fixes #11234

changelog: new lint: [cfg_not_test]

I don't know whether to lint only the attr or also the item associated to it. I guess this would mean putting the check in another place than check_attribute but I can't find a way to get the associated item to the attribute.

Also, I'm not sure how to document this lint, I feel like my explications are bad.

[rustbot]

r? @Jarcho

(rustbot has picked a reviewer for you, use r? to override)

[Centri3]

This won't detect it if --test is passed.

This could be a pre-expansion pass lint instead so it's ran before cfg is expanded, but these are very buggy and soft-deprecated. See #6610 for an example of one of these issues. If it's made into a pre-expansion pass, this should probably be moved to attrs.rs and combined with maybe_misused_cfg, that way we can minimize its usage to only a few lints.

Whether or not it not detecting it if --test is passed is an issue is up to you, it's probably not as big of a deal as other lints.

[mrnossiom]

I didn't know about cfg expansion, does this only concern cfg_attr? or does normal cfgs get expanded too ? If cfg_attr can be expanded, should I change my lint to be a late pass ? I've also read in other issues that many attribute lints had issues in early pass.

Concerning attrs.rs, I saw the file but choose to follow the Clippy dev book. I don't know if grouping lints has an advantage (btw, why isn't there more folders for lints?). Also, this deserves his own lint, and IMHO has not much to do with maybe_misused_cfg.

Last, I didn't exactly understand the issue about the --test flag.

[Centri3]

I didn't know about cfg expansion, does this only concern cfg_attr?

No, it concerns cfg as well. In the HIR, and even AST, cfgs are expanded to either nothing or unchanged depending on whether it should "be in that compilation run". So, if not(test) is successful, it'll be entirely gone before linting occurs. Thus, if the user passes --test, there will be no warnings.

For something like not(test), not a big deal, but something like cfg(all(windows, not(test)) is not good.

I'd recommend messing around a bit on godbolt if you're still having trouble understanding: https://godbolt.org/z/WxPWeM416, you can see the AST before macro-expansion, after, and the HIR by passing different things to unpretty.

(btw, why isn't there more folders for lints?)

Only because nobody's taken the time to :D I'd be 100% in favor of merging a PR to clean that up a bit.

I don't know if grouping lints has an advantage

It's cleaner, but more importantly, it puts them in the same lint pass which has a huge performance boost. For on-by-default (warn/deny) lints, that you almost never want to globally disallow, this is great. In the case of this lint, it's allow-by-default, but I'd still say it's ok in the same lint pass as it does the exact same thing as other lints.

Also, this deserves his own lint, and IMHO has not much to do with maybe_misused_cfg.

I actually agree now; that one is warn-by-default and this one is a restriction lint. So, no complaints from me.

[mrnossiom]

I'm going to see for the expansion

merging a PR to clean that up a bit.

Would definitely be willing to do that 😉

In the case of this lint, it's allow-by-default

I thought restriction was warn-by-default (it's not). In the original issue, @blyxyas states "I feel like the drawback is too heavy for an allow-by-default lint" which I understand as "the lint should be warn-by-default"

[Centri3]

I think she meant enabled-by-default, restriction is allow-by-default and generally, lints in that group aren't applicable in every situation or go against idiomatic code. There are valid reasons for using not(test).

For an example of when it's not quite as applicable, maybe when getting coverage they'd have a cfg set using RUSTFLAGS and use any(not(test), coverage) to include it in coverage but not testing, perhaps to speed up compilation.

[blyxyas]

I thought restriction was warn-by-default (it's not). In the original issue, @blyxyas states "I feel like the drawback is too heavy for an allow-by-default lint" which I understand as "the lint should be warn-by-default"

Totally a typo, it should not be warn by default imo

[bors]

☔ The latest upstream changes (presumably #11373) made this pull request unmergeable. Please resolve the merge conflicts.

[Jarcho]

LGTM, but since you were already reviewing this. r? @Centri3

[rustbot]

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git rebase -i master
$ # delete any merge commits in the editor that appears
$ git push --force-with-lease

The following commits are merge commits:

• e80f48b

[bors]

☔ The latest upstream changes (presumably #11362) made this pull request unmergeable. Please resolve the merge conflicts.

[xFrednet]

@Centri3 is currently inactive. @Jarcho would you mind taking this review back? If you don't have the time rn, you can reassign it using r? clippy or to me :)

r? @Jarcho

[mrnossiom]

Hi @Jarcho,

It's been a little time since I've made this PR. I would love to finish it. I remember being blocked by not understanding exactly what was blocking.

If I am correct, early passes are kind of unstable and buggy, but the information I need is not available after cfg expansion ? Or are cfg's expanded before early passes ?

[Jarcho]

Early passes are fine and have access to the ast before any cfg based removal has happened. The passes we don't want to add are pre-expansion passes, but that's not needed for this.

[mrnossiom]

So this PR is good as is, then ?