merge DefKind::InlineConst into AnonConst by khyperia · Pull Request #158767 · rust-lang/rust

khyperia · 2026-07-04T08:20:18Z

This is a closely related followup to #158375 (a condition of merging that PR was doing this as a followup)

This merge conflicts with #158617 ; prefer merging that one first please~

This PR is within the general goal of const generics / generic_const_args and perhaps specifically rust-lang/project-const-generics#108 but is mostly a code cleanup rather than implementing any particular feature

Anon consts (the 1 + 2 in let x: [u8; 1 + 2];) are closely related to inline consts (the const {} in let x = const { 1 + 2 };). They are especially related now that both can be used in the type system (by the above PR) and should be treated identically in that scenario. In general, they should be treated the same, as evidenced by the number of matches touched in this PR that just match on both. This PR merges the two DefKinds into one, mostly arbitrarily and bikesheddily choosing to use the name AnonConst for the merged concept (e.g. both DefKind::InlineConst and DefKind::AnonConst used ast::AnonConst, so ast::AnonConst should probably be named whatever the merged DefKind concept is named).

When you absolute must distinguish between the two, tcx.anon_const_kind allows you to do so - however, anon consts/inline consts in the type system intentionally appear identically under anon_const_kind. Indeed, the places where we distinguish between the two raised my eyebrows a few times when doing this PR, and being a little more explicit and loud about it is helpful for code clarity, IMO.

r? @BoxyUwU

rustbot · 2026-07-04T08:20:22Z

This PR changes rustc_public

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

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

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

cc @rust-lang/clippy

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

HIR ty lowering was modified

cc @fmease

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

rustbot · 2026-07-04T08:20:24Z

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

khyperia · 2026-07-04T08:34:58Z

+            kind: hir::ExprKind::ConstBlock(..) | hir::ExprKind::InlineAsm(..),
+            ..
+        }) => ty::AnonConstKind::NonTypeSystemInline,
+        _ => ty::AnonConstKind::NonTypeSystemAnon,


I am unsure about this catch-all, tbh. There's three options I see:

leave it as a catch-all

explicitly list which parents are allowed to have an AnonConst child, panic if there's an unexpected parent

afaik it's just Node::Field and Node::Variant

add variants to AnonConstKind that actually list which specific kind of anon const this non-type-system anon const is - for example, having the AnonConstKind variants of ConstBlock, AsmConstBlock, FieldAnonConst, VariantAnonConst, and then perhaps a fn AnonConstKind::is_type_system() -> bool or somethin'

there's a few callers that we match on the hir parent again to figure out which type of non-type-system anon const it is, so just returning it here seems useful

View changes since the review

it might make sense to make this NonTypeSystem(NonTypeSystemAnonConstKind) (better name pending) 🤔 unsure :3 I like the option of specifying which kind of anon const it is if that makes a lot of callers simpler (and it's weird to only do it for inline vs non inline lol)

khyperia · 2026-07-04T08:42:48Z

                // Field defaults are allowed to use generic parameters, e.g. `field: u32 = /*defid: N + 1*/`
-                ty::AnonConstKind::NonTypeSystem
+                ty::AnonConstKind::NonTypeSystemAnon
                    if matches!(tcx.parent_hir_node(hir_id), Node::TyPat(_) | Node::Field(_)) =>


Node::TyPat(_) appears to be dead code here - or at the very least, it's untested, replacing it with a panic and ./x test tests/ui does not fire. Was added in #136284 and code has been heavily refactored since then - haven't fully investigated yet.

View changes since the review

hmm yeah I wouldn't expect pattern types to contain non type system anon consts? that feels weird :3

khyperia · 2026-07-04T08:46:17Z

-            ExprKind::ConstBlock(constant) => {
-                for attr in &expr.attrs {
-                    visit::walk_attribute(self, attr);
-                }
-
-                let def = self
-                    .create_def(constant.id, None, DefKind::InlineConst, constant.value.span)
-                    .def_id();
-                // use specifically walk_anon_const, not walk_expr, to skip self.visit_anon_const
-                self.with_parent(def, |this| visit::walk_anon_const(this, constant));
-            }


yippee, less def_collector jank!

View changes since the review

BoxyUwU · 2026-07-07T11:13:02Z

    ForeignMod,
-    /// Anonymous constant, e.g. the `1 + 2` in `[u8; 1 + 2]`.
+    /// Anonymous constant, e.g. the `1 + 2` in `[u8; 1 + 2]`, or an inline
+    /// constant, e.g. `const { 1 + 2 }`.


we might want to be more explicit that there are other kinds of anon consts too (e.g. enum discriminants)

View changes since the review

BoxyUwU · 2026-07-07T11:14:26Z

                // Field defaults are allowed to use generic parameters, e.g. `field: u32 = /*defid: N + 1*/`
-                ty::AnonConstKind::NonTypeSystem
+                ty::AnonConstKind::NonTypeSystemAnon
                    if matches!(tcx.parent_hir_node(hir_id), Node::TyPat(_) | Node::Field(_)) =>


hmm yeah I wouldn't expect pattern types to contain non type system anon consts? that feels weird :3

BoxyUwU · 2026-07-07T11:23:37Z

        // Also skip items for which typeck forwards to parent typeck.
        if !(def_kind == DefKind::AnonConst
-            || def_kind == DefKind::InlineConst && tcx.is_type_system_inline_const(item_def_id)
+            && tcx.anon_const_kind(item_def_id) != ty::AnonConstKind::NonTypeSystemInline


this now allows feeding type_of for NonTypeSystemAnon I guess? I think that's unintentional?

View changes since the review

It was previously allowed! This is one of the cases where my eyebrows were raised:

Indeed, the places where we distinguish between the two raised my eyebrows a few times when doing this PR, and being a little more explicit and loud about it is helpful for code clarity, IMO.

With this PR, before this PR, as well as before #158375 we blindly accepted all DefKind::AnonConsts here, including non type system ones. I tried to keep the existing behavior as close as possible, with the intent of making wonky behavior more apparent. If you think the behavior should change, I'll look into it!

oh that's quite fun, I would expect we never feed non type system anon consts lol. cc @oli-obk

fine to keep behaviour the same for this PR

BoxyUwU · 2026-07-07T11:31:06Z

-                            DefKind::InlineConst,
-                            anon_const.value.span,
-                        )
+                        .create_def(anon_const.id, None, DefKind::AnonConst, anon_const.value.span)


i did not previously know we used DefKind::InlineConst for inline asm stuff lol 😅

View changes since the review

BoxyUwU · 2026-07-07T11:32:40Z

        // the interesting parts are solely in the signature of the containing item's opaque type
        // or dyn type.
-        DefKind::InlineConst | DefKind::Closure | DefKind::SyntheticCoroutineBody => {}
+        DefKind::AnonConst | DefKind::Closure | DefKind::SyntheticCoroutineBody => {}


can we actually put the DefKind::AnonConst handling up next to the other arm about AnonConst. rn for this arm to make sense and not give alarm bells you need to have the context of the other arm :3

View changes since the review

BoxyUwU · 2026-07-07T11:37:15Z

+            kind: hir::ExprKind::ConstBlock(..) | hir::ExprKind::InlineAsm(..),
+            ..
+        }) => ty::AnonConstKind::NonTypeSystemInline,
+        _ => ty::AnonConstKind::NonTypeSystemAnon,


it might make sense to make this NonTypeSystem(NonTypeSystemAnonConstKind) (better name pending) 🤔 unsure :3 I like the option of specifying which kind of anon const it is if that makes a lot of callers simpler (and it's weird to only do it for inline vs non inline lol)

merge DefKind::InlineConst into AnonConst

2b5837c

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. labels Jul 4, 2026

rustbot assigned BoxyUwU Jul 4, 2026

rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jul 4, 2026

khyperia commented Jul 4, 2026

View reviewed changes

BoxyUwU reviewed Jul 7, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

khyperia commented Jul 4, 2026

Uh oh!

rustbot commented Jul 4, 2026

Uh oh!

rustbot commented Jul 4, 2026

Uh oh!

khyperia Jul 4, 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!

BoxyUwU Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

khyperia Jul 4, 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!

BoxyUwU Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

khyperia Jul 4, 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!

BoxyUwU Jul 7, 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!

BoxyUwU Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Jul 7, 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!

khyperia Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

BoxyUwU Jul 7, 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!

BoxyUwU Jul 7, 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!

BoxyUwU Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

khyperia Jul 4, 2026 •

edited by rustbot

Loading

khyperia Jul 4, 2026 •

edited by rustbot

Loading

khyperia Jul 4, 2026 •

edited by rustbot

Loading

BoxyUwU Jul 7, 2026 •

edited by rustbot

Loading

BoxyUwU Jul 7, 2026 •

edited by rustbot

Loading

BoxyUwU Jul 7, 2026 •

edited by rustbot

Loading

BoxyUwU Jul 7, 2026 •

edited by rustbot

Loading