Support underscore as associated const name - #158970
Conversation
This comment has been minimized.
This comment has been minimized.
|
This PR changes rustc_public cc @oli-obk, @celinval, @ouz-a HIR ty lowering was modified cc @fmease
cc @rust-lang/clippy These commits modify Please ensure that if you've changed the output:
cc @obi1kenobi |
|
r? @jackh726 rustbot has assigned @jackh726. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
e803c41 to
c664e8b
Compare
|
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. |
| /// 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)) | ||
| } |
There was a problem hiding this comment.
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.
| } | ||
| (ty::AssocKind::Const { name, .. }, ty::AssocContainer::Trait) => { | ||
| (ty::AssocKind::Const { .. }, ty::AssocContainer::Trait) => { | ||
| let name = this.item.name(); |
There was a problem hiding this comment.
I would rather use name.expect(...) than this (here and elsewhere).
| 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>, |
There was a problem hiding this comment.
:/ is this really necessary? Why not use opt_item_name in decoder?
| } | ||
| } | ||
| DefKind::AssocFn | DefKind::AssocConst { .. } | DefKind::AssocTy => { | ||
| // As with free constants named `_`, associated constants named `_` are always live. |
There was a problem hiding this comment.
"live" -> "dead"?
| 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() { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I suppose there is the impl_kind check?
| impl Public { | ||
| const _: Private = Private; | ||
| } | ||
|
|
||
| impl Private { | ||
| pub const _: Private = Private; | ||
| pub const _: () = {}; | ||
| } |
There was a problem hiding this comment.
Curious why these don't trigger the dead code lint?
| const _: () = panic!(); | ||
| const _: () = assert!(false); | ||
| const _: [(); { | ||
| { | ||
| assert!(std::mem::size_of::<Self>() == 0) | ||
| }; | ||
| 0 | ||
| }] = []; | ||
| const _: [(); { | ||
| { | ||
| assert!(true) | ||
| }; | ||
| 0 | ||
| }] = []; |
There was a problem hiding this comment.
I would expect these all to trigger dead code lints?
This PR doesn't change the current behavior of the
dead_codelint 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 ofin_definition_order(), though I'm not quite sure.Unresolved questions:
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: