Enabling keyword_idents lints doesn't warn about violations in other files

[Zalathar]

Consider this tiny two-file crate:

// main.rs
#![deny(keyword_idents)]

mod submod;

fn main() {}

// submod.rs
fn async() {}
fn await() {}
fn try() {}
fn dyn() {}
fn gen() {}

Building this crate should fail with several violations of the keyword_idents_2018 and keyword_idents_2024 lints. But instead, building unexpectedly succeeds!

(This particular example requires Rust 2015, but the same issue can be observed in 2018/2021 regarding the gen keyword only.)

[Zalathar]

I can reproduce this on 1.81-stable and 1.84-nightly/dev. No idea how old it is.

It seems to affect all of keyword_idents, keyword_idents_2018, and keyword_idents_2024.

If I put #![deny(keyword_idents)] inside submod.rs, the errors are reported as expected.

[Zalathar]

Discovered while investigating CI failures in #132167.

[ehuss]

Thanks for the report! To clarify, the example should probably be built with edition 2015 (otherwise, the lint intentionally doesn't fire in editions >= when the keyword was added).

In general, this isn't a problem for edition migrations because it works correctly when the lint is passed on the command-line (which is how cargo fix works).

It looks like the pre-expansion lint pass is not able to propagate attribute-based lint level changes to nested modules. It does not have all the machinery that the normal lint passes have for propagating levels like that. For example, here it only passes in the attributes on the module.

cc @compiler-errors. Unless this seems like it would be easy to fix, I personally would lean towards not fixing it and documenting the limitation of pre-expansion lints, and to further emphasize in comments and the documentation (like it does here) that pre-expansion lints should be avoided unless absolutely necessary. Pre-expansion lints are soft deprecated since they have known limitations.

[Zalathar]

To clarify, the example should probably be built with edition 2015 (otherwise, the lint intentionally doesn't fire in editions >= when the keyword was added).

Yes, though I should explicitly note that keyword_idents_2024 still has the same issue for the gen keyword when the crate edition is 2018 or 2021.

[traviscross]

@rustbot labels -A-edition-2024

This isn't particularly related to Rust 2024, so we're going to drop that label.