Skip to content

Support underscore as associated const name - #158970

Open
makai410 wants to merge 1 commit into
rust-lang:mainfrom
makai410:us-assoc-cnst
Open

Support underscore as associated const name#158970
makai410 wants to merge 1 commit into
rust-lang:mainfrom
makai410:us-assoc-cnst

Conversation

@makai410

@makai410 makai410 commented Jul 8, 2026

Copy link
Copy Markdown
Member

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() instead of in_definition_order(), though I'm not quite sure.

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:

@rustbot 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
@rust-log-analyzer

This comment has been minimized.

@rustbot 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 makai410 changed the title [WIP] Support underscore as associated const name Support underscore as associated const name Jul 27, 2026
@rustbot rustbot added the T-clippy Relevant to the Clippy team. label Jul 29, 2026
@makai410
makai410 marked this pull request as ready for review July 30, 2026 03:06
@rustbot

rustbot commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

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

rustbot commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

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

@rust-bors

This comment has been minimized.

@rustbot

This comment has been minimized.

@rust-bors

This comment has been minimized.

- Adds `data: AssocConstData` to `AssocKind` to properly handle
anonymous associated consts in ty.

- Adds `named_items()` to `AssocItems` and changes some uses of
`in_definition_order()` to use it instead.
@rustbot

rustbot commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator

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.

Comment on lines +294 to +297
/// 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))
}

@jackh726 jackh726 Aug 15, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

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

@jackh726 jackh726 Aug 15, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

View changes since the review

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>,

@jackh726 jackh726 Aug 15, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

View changes since the review

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

@jackh726 jackh726 Aug 15, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

"live" -> "dead"?

View changes since the review

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

@jackh726 jackh726 Aug 15, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I suppose there is the impl_kind check?

Comment on lines +13 to +20
impl Public {
const _: Private = Private;
}

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

@jackh726 jackh726 Aug 15, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

View changes since the review

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

@jackh726 jackh726 Aug 15, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I would expect these all to trigger dead code lints?

View changes since the review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants