rustc_lint: Allow scoped non_ascii_idents lint levels#157497
Conversation
This comment has been minimized.
This comment has been minimized.
`non_ascii_idents` was marked `crate_level_only`, and its diagnostic was emitted from the crate-wide symbol gallery. Move the lint into the scoped early lint visitor, checking both AST idents and macro token streams. Keep the one-diagnostic-per-ident behavior by deduplicating by ident and effective lint level/expectation, and leave the other Unicode security lints crate-level-only.
| fn check_ident_token(&mut self, cx: &EarlyContext<'_>, ident: Ident) { | ||
| let symbol = ident.name; | ||
| let symbol_str = symbol.as_str(); | ||
| if symbol_str.is_ascii() || symbol_str.starts_with('\'') { |
There was a problem hiding this comment.
Is there a reason we're ignoring lifetime names here? I would have assumed that lifetimes should also be handled by this lint (although a quick check of the current logic it does seem like we don't?)
There was a problem hiding this comment.
I'd be happy to include lifetime names here too if you think that's appropriate.
There was a problem hiding this comment.
Doing so might cause us to have to delay landing this PR (as we'll have to run crater to make sure we don't suddenly regress a lot of crates). Would you mind doing that as a follow up though?
There was a problem hiding this comment.
Sure. Is there a standard or blessed way of stacking PRs in this repo? Or should I just remember to push a new PR once this one has merged?
Linux is built with `-Dnon_ascii_idents`. However, `zerocopy-derive`
uses a non-ASCII character (`ẕ`) internally, which in turn triggers
the lint when attempting to use derives like `FromBytes`:
error: identifier contains non-ASCII characters
--> rust/kernel/lib.rs:153:9
|
153 | a: u32,
| ^
|
= note: requested on the command line with `-D non-ascii-idents`
This was already noticed by another project using
`#![deny(non_ascii_idents)]` [1]. `zerocopy` added an
`#[allow(non_ascii_idents)]` [2], but it does not work since, at the
moment, the `non_ascii_idents` lint is a `crate_level_only` one, and thus
`allow`s only work at the crate root level.
Due to this, an issue about relaxing this restriction was created in
upstream Rust [3] some months ago.
Thus work around it here by using another prefix. The likelihood of a
collision is very small for us, since we control the callers, and this
will hopefully be fixed soon at either the `zerocopy` or the Rust level.
I filed an issue [4] about it with upstream `zerocopy` as requested
and we discussed this with upstream Rust and `zerocopy`: the Rust issue
got nominated and a PR [5] to relax the restriction was submitted by
Joshua. Upstream `zerocopy` prefers that approach, so if Rust merges it,
then it means we will be able to remove the workaround when we bump the
MSRV, thus likely late 2027, since we follow Debian Stable.
Cc: Joshua Liebow-Feeser <joshlf@google.com>
Cc: Jack Wrenn <jswrenn@google.com>
Link: google/zerocopy#2880 [1]
Link: google/zerocopy#2882 [2]
Link: rust-lang/rust#151025 [3]
Link: google/zerocopy#3427 [4]
Link: rust-lang/rust#157497 [5]
Link: https://patch.msgid.link/20260608141439.182634-16-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
non_ascii_identswas markedcrate_level_only, and its diagnostic was emitted from the crate-wide symbol gallery.Move the lint into the scoped early lint visitor, checking both AST idents and macro token streams. Keep the one-diagnostic-per-ident behavior by deduplicating by ident and effective lint level/expectation, and leave the other Unicode security lints crate-level-only.
Fixes #151025
r? @jswrenn