Support underscore as associated const name in inherent impls by makai410 · Pull Request #158970 · rust-lang/rust

makai410 · 2026-07-08T19:00:34Z

This PR doesn't change the current behavior of the dead_code lint for unused associated consts with underscore-prefixed names and treats associated consts named _ consistently.

There might still be some places that should've been changed to use named_items_in_definition_order() instead of in_definition_order(), though I'm not quite sure.

The RFC does not propose const underscore inside traits or trait impls, so this PR only implements support for const underscore in inherent impls.

Unresolved questions:

Whether to lint impl Private { pub const _: Private = Private; }, where the visibility qualifier here has no effect. It seems like there wasn't any disagreement on linting this, though what's proposed in the RFC currently diverges from that: RFC: Associated const underscore.

Tracking:

Tracking issue for RFC 3527: Associated const underscore #158944

rustbot · 2026-07-30T03:06:38Z

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a

HIR ty lowering was modified

cc @fmease

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

It's intentional.
The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @obi1kenobi

rustbot · 2026-07-30T03:06:41Z

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 74 candidates
Random selection from 16 candidates

jackh726 · 2026-08-15T17:59:37Z

+    /// Returns named associated items in definition order.
+    pub fn named_items(&self) -> impl '_ + Iterator<Item = &ty::AssocItem> {
+        self.items.iter().filter_map(|(name, v)| name.is_some().then(|| v))
+    }


I have a slight issue with adding this function.

The comment on in_definition_order has a comment about new code; this function doesn't have that comment. It's each to accidentally rely on definition order with realizing. So - at the very least that comment needs to be added here too.

Second, it makes me slightly worried that someone might use this when they should have been iterating over all items.

View changes since the review

Would a rename to named_items_in_defnition_order make sense here?

jackh726 · 2026-08-15T18:00:32Z

                    }
-                    (ty::AssocKind::Const { name, .. }, ty::AssocContainer::Trait) => {
+                    (ty::AssocKind::Const { .. }, ty::AssocContainer::Trait) => {
+                        let name = this.item.name();


I would rather use name.expect(...) than this (here and elsewhere).

View changes since the review

Here this.item.name() already does opt_name().expect(...), with the same error message. Would that be enough? Or were you suggesting we shouldn't change the AssocKind::Const representation from { name: Symbol, ... } -> { data: AssocConstData, ... }?

Sorry, let me say more:

By calling this.item.name() we are now introducing a panic path that was there before - and one that's hidden through indirection at that.

Looking at this with fresh eyes, I actually think that we should have separate match arms and be explicit about what we're doing, rather than rely on a panic in AssocItem::name.

Sorry for the delay >_<. I do think you have a point, and I've done what you suggested

jackh726 · 2026-08-15T18:03:41Z

    explicit_implied_const_bounds: Table<DefIndex, LazyArray<(ty::PolyTraitRef<'static>, Span)>>,
    inherent_impls: Table<DefIndex, LazyArray<DefIndex>>,
    opt_rpitit_info: Table<DefIndex, Option<LazyValue<ty::ImplTraitInTraitData>>>,
+    is_anon_assoc_const: Table<DefIndex, bool>,


:/ is this really necessary? Why not use opt_item_name in decoder?

View changes since the review

I was thinking more about the perf issue(?) Intuitively bool should be cheaper than Symbol? But I just found that Symbol is interned so Option<Symbol> only takes up 4 bytes when reading the doc. So yeah I suppose that doesn't matter that much, so let's go with it :P

jackh726 · 2026-08-15T18:04:33Z

            }
        }
        DefKind::AssocFn | DefKind::AssocConst { .. } | DefKind::AssocTy => {
+            // As with free constants named `_`, associated constants named `_` are always live.


"live" -> "dead"?

View changes since the review

jackh726 · 2026-08-15T18:08:51Z

    let kind = match impl_item.kind {
        hir::ImplItemKind::Const(_, rhs) => {
-            ty::AssocKind::Const { name, is_type_const: matches!(rhs, ConstItemRhs::TypeConst(_)) }
+            let data = if impl_item.is_anon_const() {


This can just look at name directly? Is hir::ImplItem::is_anon_const used elsewhere? There are extra checks there that aren't meaningful because we already know that is a Const impl item, right?

View changes since the review

I suppose there is the impl_kind check?

I think that very much depends on if the ImplItemImplKind (or say ty::AssocContainer) says it's an inherent impl. We could drop the anon const check if the context here is definitely an inherent impl, but I don't think that's guaranteed since this associated_item_from_impl_item() function can accept any kind of impl item in any context, and then return the corresponding ty::AssocItem, no? Or am I missing something?

jackh726 · 2026-08-15T18:18:14Z

+impl Public {
+    const _: Private = Private;
+}
+
+impl Private {
+    pub const _: Private = Private;
+    pub const _: () = {};
+}


Curious why these don't trigger the dead code lint?

View changes since the review

jackh726 · 2026-08-15T18:19:14Z

+    const _: () = panic!();
+    const _: () = assert!(false);
+    const _: [(); {
+        {
+            assert!(std::mem::size_of::<Self>() == 0)
+        };
+        0
+    }] = [];
+    const _: [(); {
+        {
+            assert!(true)
+        };
+        0
+    }] = [];


I would expect these all to trigger dead code lints?

View changes since the review

As I said in the PR description, I intentionally kept the behavior of dead code lints on both underscore and underscore-prefixed associated consts as is. Currently if you write const _foo: () = {};, it won't trigger the dead code lint: playground.

I did this since one could argue that "I already prefixed/named it with underscore, why did rustc still warn me it's dead code?". I'd personally propose a new lint to teach users that they won't be evaluated if they're never accessed, rather than teaching them through the dead code lint. I kinda tend to agree with rust-lang/rfcs#3527 (comment) to some extent.

So at the very least, it's debatable. Let's just keep it as is for now and discuss this later.

rust-bors · 2026-11-10T12:57:12Z

📌 Commit 5baf366 has been tentatively approved by jackh726,fmease

It will be put into the queue for this repository once PR CI succeeds.

…,fmease Support underscore as associated const name in inherent impls This PR doesn't change the current behavior of the `dead_code` lint for unused associated consts with underscore-prefixed names and treats associated consts named `_` consistently. There might still be some places that should've been changed to use `named_items_in_definition_order()` instead of `in_definition_order()`, though I'm not quite sure. [The RFC](https://github.com/dtolnay/rfcs/blob/assocunderscore/text/0000-associated-const-underscore.md#reference-level-explanation) does not propose const underscore inside traits or trait impls, so this PR only implements support for const underscore in inherent impls. Unresolved questions: - Whether to lint `impl Private { pub const _: Private = Private; }`, where the visibility qualifier here has no effect. It seems like there wasn't any disagreement on linting this, though what's proposed in the RFC currently diverges from that: [RFC: Associated const underscore](https://github.com/dtolnay/rfcs/blob/assocunderscore/text/0000-associated-const-underscore.md#reference-level-explanation). Tracking: - rust-lang#158944

…uwer Rollup of 8 pull requests Successful merges: - #158970 (Support underscore as associated const name in inherent impls) - #165192 (BPF: Define max/min atomic width per CPU version) - #165611 (Avoid terminator: None in MIR building) - #165749 (Improve duplicate attribute diagnostics for active built-in attributes) - #165762 (Fix `x bench library/std`) - #165726 ([rustdoc-frontend] Properly clear search state when sidebar link is clicked) - #165728 (Disable no_threads compiler errors for Trusty targets) - #165754 (rustdoc: Rename `--show-coverage` CLI flag into `--coverage`)

rust-bors · 2026-11-10T20:37:08Z

⌛ Testing commit 5baf366 with merge d43c99d...

Workflow: https://github.com/rust-lang/rust/actions/runs/42897069548

Support underscore as associated const name in inherent impls This PR doesn't change the current behavior of the `dead_code` lint for unused associated consts with underscore-prefixed names and treats associated consts named `_` consistently. There might still be some places that should've been changed to use `named_items_in_definition_order()` instead of `in_definition_order()`, though I'm not quite sure. [The RFC](https://github.com/dtolnay/rfcs/blob/assocunderscore/text/0000-associated-const-underscore.md#reference-level-explanation) does not propose const underscore inside traits or trait impls, so this PR only implements support for const underscore in inherent impls. Unresolved questions: - Whether to lint `impl Private { pub const _: Private = Private; }`, where the visibility qualifier here has no effect. It seems like there wasn't any disagreement on linting this, though what's proposed in the RFC currently diverges from that: [RFC: Associated const underscore](https://github.com/dtolnay/rfcs/blob/assocunderscore/text/0000-associated-const-underscore.md#reference-level-explanation). Tracking: - #158944

JonathanBrouwer · 2026-11-10T20:42:10Z

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #165775 (comment)

rust-bors · 2026-11-10T20:42:20Z

This pull request was unapproved.

This PR was contained in a rollup (#165775), which was unapproved.

Auto build was cancelled due to unapproval. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/42897069548

View changes since this unapproval

Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>

makai410 · 2026-11-11T08:34:34Z

The check failed because #164217 had been merged right before the run, which added a new field to WorkItem. I'll just rebase this

rustbot · 2026-11-11T08:37:39Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

makai410 · 2026-11-11T10:30:55Z

I don't think we need to bother running a try job here so I'm going to r= this outright (fingers crossed)

@bors r=jackh726,fmease

rust-bors · 2026-11-11T10:30:59Z

📌 Commit 5b3196f has been approved by jackh726,fmease

It is now in the queue for this repository.

…uwer Rollup of 8 pull requests Successful merges: - #165522 (Add relnotes for 1.100) - #158970 (Support underscore as associated const name in inherent impls) - #164582 (Properly feature gate doc(rust_logo)) - #165680 (Update call to llvm::codegen::InitTargetOptionsFromCodeGenFlags) - #165768 (Bail out ill-formed aliases when assembling trait object bounds candidates) - #165776 (docs: Fix a typo in rustc-dev-guide [NFC]) - #165797 (Disable flaky `tests/debuginfo/basic-stepping.rs` on aarch64 msvc) - #165798 (Add a regression test for fixed next-solver ICE)

Rollup merge of #158970 - makai410:us-assoc-cnst, r=jackh726,fmease Support underscore as associated const name in inherent impls This PR doesn't change the current behavior of the `dead_code` lint for unused associated consts with underscore-prefixed names and treats associated consts named `_` consistently. There might still be some places that should've been changed to use `named_items_in_definition_order()` instead of `in_definition_order()`, though I'm not quite sure. [The RFC](https://github.com/dtolnay/rfcs/blob/assocunderscore/text/0000-associated-const-underscore.md#reference-level-explanation) does not propose const underscore inside traits or trait impls, so this PR only implements support for const underscore in inherent impls. Unresolved questions: - Whether to lint `impl Private { pub const _: Private = Private; }`, where the visibility qualifier here has no effect. It seems like there wasn't any disagreement on linting this, though what's proposed in the RFC currently diverges from that: [RFC: Associated const underscore](https://github.com/dtolnay/rfcs/blob/assocunderscore/text/0000-associated-const-underscore.md#reference-level-explanation). Tracking: - #158944

Upstream rustc replaced `ty::AssocKind::Const { name }` with `ty::AssocKind::Const { data: AssocConstData }` in rust-lang/rust#158970 (commit `5b3196fcd42db0cca7df744bf0efc84b4c0d8f37`) to support anonymous associated constants (`const _: ...` and `pub const _: ...`). Use `assoc_item.opt_name()` instead of destructuring `name` on `ty::AssocKind::Const` so `cc_bindings_from_rs` builds against both old and new toolchains, and skip nameless anonymous associated constants in `generate_cpp_enum` and `generate_associated_item` (matching module-level underscore constants). PiperOrigin-RevId: 1019241616

Upstream rustc replaced `ty::AssocKind::Const { name }` with `ty::AssocKind::Const { data: AssocConstData }` in rust-lang/rust#158970 (commit `5b3196fcd42db0cca7df744bf0efc84b4c0d8f37`) to support anonymous associated constants (`const _: ...` and `pub const _: ...`). Use `assoc_item.opt_name()` instead of destructuring `name` on `ty::AssocKind::Const` so `cc_bindings_from_rs` builds against both old and new toolchains, and skip nameless anonymous associated constants in `generate_cpp_enum` and `generate_associated_item` (matching module-level underscore constants). PiperOrigin-RevId: 1019451675

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 8, 2026

This comment has been minimized.

Sign in to view

makai410 force-pushed the us-assoc-cnst branch from f17f19f to b10ada5 Compare July 27, 2026 17:56

rustbot added A-rustdoc-json Area: Rustdoc JSON backend T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Jul 27, 2026

makai410 changed the title ~~[WIP] Support underscore as associated const name~~ Support underscore as associated const name Jul 27, 2026

makai410 force-pushed the us-assoc-cnst branch from b10ada5 to 17b62f7 Compare July 29, 2026 08:22

rustbot added the T-clippy Relevant to the Clippy team. label Jul 29, 2026

makai410 force-pushed the us-assoc-cnst branch from 17b62f7 to e91ca1c Compare July 29, 2026 14:29

makai410 marked this pull request as ready for review July 30, 2026 03:06

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 30, 2026

rustbot assigned jackh726 Jul 30, 2026

This comment has been minimized.

Sign in to view

makai410 force-pushed the us-assoc-cnst branch from e91ca1c to e803c41 Compare August 6, 2026 22:00

This comment has been minimized.

Sign in to view

makai410 force-pushed the us-assoc-cnst branch from e803c41 to c664e8b Compare August 14, 2026 14:18

This comment has been minimized.

Sign in to view

jackh726 reviewed Aug 15, 2026

View reviewed changes

jackh726 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 20, 2026

This comment has been minimized.

Sign in to view

makai410 force-pushed the us-assoc-cnst branch from c664e8b to 82ef566 Compare October 6, 2026 15:33

This comment has been minimized.

Sign in to view

makai410 force-pushed the us-assoc-cnst branch from 82ef566 to 5c63523 Compare October 6, 2026 15:56

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 10, 2026

JonathanBrouwer mentioned this pull request Nov 10, 2026

Rollup of 8 pull requests #165775

Closed

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 10, 2026

This comment has been minimized.

Sign in to view

Support underscore as associated const name in inherent impls

5b3196f

Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>

makai410 force-pushed the us-assoc-cnst branch from 5baf366 to 5b3196f Compare November 11, 2026 08:37

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 11, 2026

JonathanBrouwer mentioned this pull request Nov 11, 2026

Rollup of 8 pull requests #165808

Merged

rust-bors Bot merged commit e7c7e1a into rust-lang:main Nov 11, 2026
14 checks passed

rustbot added this to the 1.102.0 milestone Nov 11, 2026

makai410 mentioned this pull request Nov 11, 2026

Tracking issue for RFC 3527: Associated const underscore #158944

Open

1 of 6 tasks

copybara-service Bot mentioned this pull request Nov 11, 2026

Support anonymous associated constants in cc_bindings_from_rs google/crubit#2927

Merged

Conversation

makai410 commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Jul 30, 2026

Uh oh!

rustbot commented Jul 30, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

jackh726 Aug 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

makai410 Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Aug 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Aug 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

makai410 Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Aug 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Aug 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Aug 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Aug 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Nov 10, 2026

Uh oh!

rust-bors Bot commented Nov 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JonathanBrouwer commented Nov 10, 2026

Uh oh!

rust-bors Bot commented Nov 10, 2026

Uh oh!

This comment has been minimized.

makai410 commented Nov 11, 2026

Uh oh!

makai410 commented Jul 8, 2026 •

edited

Loading

jackh726 Aug 15, 2026 •

edited by rustbot

Loading

makai410 Oct 6, 2026 •

edited

Loading

jackh726 Aug 15, 2026 •

edited by rustbot

Loading

jackh726 Aug 15, 2026 •

edited by rustbot

Loading

makai410 Oct 6, 2026 •

edited

Loading

jackh726 Aug 15, 2026 •

edited by rustbot

Loading

jackh726 Aug 15, 2026 •

edited by rustbot

Loading

jackh726 Aug 15, 2026 •

edited by rustbot

Loading

jackh726 Aug 15, 2026 •

edited by rustbot

Loading

rust-bors Bot commented Nov 10, 2026 •

edited

Loading