Skip to content
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

unknown_lints doesn't trigger in all cfg_attr #97094

Closed
Xiphoseer opened this issue May 16, 2022 · 6 comments · Fixed by #97266
Closed

unknown_lints doesn't trigger in all cfg_attr #97094

Xiphoseer opened this issue May 16, 2022 · 6 comments · Fixed by #97266
Assignees
Labels
C-bug Category: This is a bug.

Comments

@Xiphoseer
Copy link

Xiphoseer commented May 16, 2022

I tried this code:

#![deny(warnings)]
#![cfg_attr(all(), allow(lint1))]

#[cfg_attr(all(), allow(lint2))]
mod baz {
    #![cfg_attr(all(), allow(lint3))]
}

#[cfg_attr(all(), allow(lint4))]
pub fn test() {}

Playground Link

I expected attributs in all 4 positions to cause compiler errors, but just the first one (inner attribute on the root module) does. When using allow without cfg_attr I get all 4 errors. Came across this while debugging why adding #![cfg_attr(feature = "name", allow(unused_macro_rules))] didn't introduce new warnings on stable in a module.

Meta

This happens in at least:

  • 1.60.0
  • 1.61.0-beta.7
  • nightly-2022-05-15

which are the versions currently on the playground

@est31
Copy link
Member

est31 commented May 20, 2022

This seems to have been a regression of the 1.29.0 compiler: the warnings on 1.28.0 are just fine.

The issue is that LintLevelsBuilder::push, which takes care of the unknown_lints lint, gets the attributes in a pre-cfg-expanded form, as it is called very early in compilation. But Level::from_attr, which it calls, only looks for normal attributes, as in, does not recognize cfg_attr (and it shouldn't).

For some reason, allow's behind cfg_attr still work though, and I have no clue why.

unknown_lints still works on the crate root because cfg_attr there has been expanded already.

@est31
Copy link
Member

est31 commented May 21, 2022

Expectably, as the same code also handles the renamed_and_removed_lints lint, the same issue exists if you put bare_trait_object as the lint's name in the above example.

@est31
Copy link
Member

est31 commented May 21, 2022

I think the best solution for this is to move the lints into a late lint pass. Maybe the push stuff could be called after cfg expansion but this could have side effects for other lints, idk.

@rustbot claim

@est31
Copy link
Member

est31 commented May 21, 2022

So it turns out that allowing the unknown_lints lint doesn't work either (inside cfg_attr), even though it does work for while_true, which is an early lint:

#[cfg_attr(all(), allow(unknown_lints, while_true))]
mod bar {
    #[allow(noex_inside_module)] // Warns for the unknown lint name here due to the allow above not working
    fn _foo() { while true {} } // Doesn't warn for the `while true` here due to the allow working
}

This opens the possibility of just moving the unknown_lints and renamed_and_removed_lints lints into their own early lint pass.

@est31
Copy link
Member

est31 commented May 21, 2022

Oh so apparently the push function does get called later on, but the warnings are suppressed because warn_about_weird_lints is set to false. I have missed that. So one only might have to set warn_about_weird_lints to true more early on...

@est31
Copy link
Member

est31 commented May 22, 2022

I've made a PR: #97266

@bors bors closed this as completed in 896a59d May 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants