Skip to content

rustc_lint: Allow scoped non_ascii_idents lint levels#157497

Open
joshlf wants to merge 1 commit into
rust-lang:mainfrom
joshlf:non-ascii-idents
Open

rustc_lint: Allow scoped non_ascii_idents lint levels#157497
joshlf wants to merge 1 commit into
rust-lang:mainfrom
joshlf:non-ascii-idents

Conversation

@joshlf

@joshlf joshlf commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

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.

Fixes #151025

r? @jswrenn

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 5, 2026
@rustbot

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('\'') {

@estebank estebank Jun 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?)

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be happy to include lifetime names here too if you think that's appropriate.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

ojeda added a commit to Rust-for-Linux/linux that referenced this pull request Jun 9, 2026
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow derives to allow(non_ascii_idents) at the non-crate level

4 participants