-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add cfg_not_test lint #11293
feat: add cfg_not_test lint #11293
Conversation
r? @Jarcho (rustbot has picked a reviewer for you, use r? to override) |
clippy_lints/src/cfg_not_test.rs
Outdated
fn check_attribute(&mut self, cx: &EarlyContext<'_>, attr: &rustc_ast::Attribute) { | ||
if let Some(ident) = attr.ident() | ||
&& ident.name == rustc_span::sym::cfg | ||
&& contains_not_test(attr.meta_item_list().as_deref(), false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know about cfg
expansion, does this only concern cfg_attr
? or does normal cfg
s 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know about
cfg
expansion, does this only concerncfg_attr
?
No, it concerns cfg
as well. In the HIR, and even AST, cfg
s 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Totally a typo, it should not be warn by default imo |
☔ The latest upstream changes (presumably #11373) made this pull request unmergeable. Please resolve the merge conflicts. |
LGTM, but since you were already reviewing this. r? @Centri3 |
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:
The following commits are merge commits: |
☔ The latest upstream changes (presumably #11362) made this pull request unmergeable. Please resolve the merge conflicts. |
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 |
Early passes are fine and have access to the ast before any |
So this PR is good as is, then ? |
If you haven't already you'll have to rebase and rebless the tests. There was a |
☔ The latest upstream changes (presumably #12937) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #12893) made this pull request unmergeable. Please resolve the merge conflicts. |
Hey, this is a ping from triage. @Jarcho can you give this PR a review? It's totally fine if you don't have the time right now, you can reassign the PR to a random team member using @mrnossiom Would you mind rebasing the PR again? @rustbot ready |
☔ The latest upstream changes (presumably #10155) made this pull request unmergeable. Please resolve the merge conflicts. |
Marked this as approved. @rust-lang/clippy can someone merge this if they see it before I do since this is now multiple times I've missed it. |
@bors r=Jarcho |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
@bors r=Jarcho |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
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 thancheck_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.