Always try to evaluate default field values and lint if it is too generic by estebank · Pull Request #163235 · rust-lang/rust

estebank · 2026-09-23T23:20:51Z

Default field values in types that have const generics are no longer being evaluated until mono. Emit a warn-by-default lint so that API designers are not caught of guard by this behavior.

warning: field `multiline_field` has a default value that is only checked when a value of `Z` is constructed
  --> $DIR/field-references-param-accurate-span.rs:9:15
   |
LL |   struct Z<const X: usize> {
LL |       multiline_field:
LL |           ()
LL |               = {
   |  _______________^
LL | |                 f::<X>();
LL | |                 panic!();
LL | |             },
   | |_____________^ this can't be const-evaluated until use
   |
   = help: structs and enums with type and const parameters only evaluate their default field values during construction, not eagerly when declared
   = note: `#[warn(unevaluated_default_field_value)]` on by default
help: if this behavior is acceptable, allow the lint and preferably write a test relying on the default value
   |
LL + #[expect(unevaluated_default_field_value)]
LL | struct Z<const X: usize> {
   |

Support Span context in lints.

Fixes #146496.
Part of #132162.
Alternative to #163182.

CC @fmease @BoxyUwU

rustbot · 2026-09-24T04:33:16Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

estebank

I don't know if this is the way we should go, but I feel like having this lint gets us most of the behavior we'd want. People can't get into a bad condition without warning, and it can be as unobtrusive as adding the allow on the crate root for those who really don't care. I just wouldn't want to have someone writing Struct<const T: u8> { field: u8 = const_fn() } and then changing that to Struct<const T: u8> { field: u8 = const_fn() + T } and then get a silent change in behavior.

View changes since this review

estebank · 2026-09-24T04:34:00Z

+                .last()
+                .map(|f| f.span)
+                .unwrap_or(ecx.tcx.span);
+            ErrorHandled::TooGeneric(span)


This change here...

estebank · 2026-09-24T04:34:57Z

+warning: field `multiline_field` has a default value that is only checked when a value of `Z` is constructed
+  --> $DIR/field-references-param-accurate-span.rs:8:15
+   |
+LL |   struct Z<const X: usize> {
+LL |       // Ensure that proper context is shown in lint.
+LL |       multiline_field:
+LL |           ()
+LL |               = {
+   |  _______________^
+LL | |                 f::<X>();
+   | |                 -------- this can't be const-evaluated until use
+LL | |                 panic!();
+LL | |             },
+   | |_____________^ unevaluated default value


...is so that we can get this, where we don't just point at the whole default field value, but also to the exact place in the const that stopped it from being eagerly computed.

estebank · 2026-09-24T04:35:40Z

+                if let Some(def_id) = field.value {
+                    if let Err(ErrorHandled::TooGeneric(span)) = tcx.const_eval_poly(def_id)


Need feedback on whether just doing this is reasonable.

Note that strictly speaking this is equally "unprincipled" in the sense that relying on when const_eval_poly returns TooGeneric "exposes" the implementation quirks of const eval.

~~On main,~~ it's particularly "egregious" because it decides whether a given program is valid or not (pre-monomorphization). ~~Under your PR it's at least a lint that can be silenced but still~~ it means that changes to const eval that are meant to be purely internal / mere refactorings might lead to the lint getting emitted in fewer or more cases [edit: please see also #163235 (comment)] (AFAIU but I'm a layperson when it comes to const eval's internals).

Moreover, I don't know if Rust's (pre-monormorphization) semantics already depends on when const eval returns TooGeneric or not for code that may reference generic parameters (I'm specific here since TooGeneric can also be returned on certain kinds of normalization failures IIRC).

To give another example (apart from the one I gave in the GH issue).

This absolutely minor change makes const_eval_poly silently bail out with TooGeneric instead of evaluating & diverging with a const panic:

#![feature(default_field_values)] struct X<T> { x: () = { - let _: T; + let _x: T; panic!() }, y: T, }

That's exactly what I mean by the word "unprincipled". Under your PR, changes like this still determine whether to lint or not. That's … not great IMHO.

On main, it's particularly "egregious" because it decides whether a given program is valid or not (pre-monomorphization). Under your PR it's at least a lint that can be silenced but still it means that changes to const eval that are meant to be purely internal / mere refactorings might lead to the lint getting emitted in fewer or more cases (AFAIU but I'm a layperson when it comes to const eval's internals).

I'm still waking up, so I'm realizing now that under your PR it of course continues to be the case that Rust's (pre-monorphization) semantics (specifically what program to accept or to reject) would depend on the whether const_eval_poly returns TooGeneric! It's just that in one case we now emit a lint (which is irrelevant when talking core semantics).

All that to say,

Fixes #146496.

sadly your PR does in fact not address this issue. Looking at the example I gave in that issue, uncommenting that innocuous-seeming line upstream still breaks downstream!

Moreover, the lint message doesn't make that clear since it's obviously only targeted towards explaining why the default isn't evaluated now to address the first paragraph(s) of your comment #163182 (comment). But it completely sweeps under the table the SemVer implications.

When I read the first paragraph(s) of your comment #163182 (comment) I thought you meant "let's take fmease's approach from PR #163182 but also emit a lint" (which would indeed affect all structs with type or const params that have field defaults, so that might be a non-starter).

We can follow your approach with a less targeted lint. We just need some feedback. The problem with your approach is that the lint will be much more noisy. My biggest concern is that addint a type param to a struct all of a sudden causes the semantics to change. That is a pretty big foot gun.

I pushed the behavior from your draft, + an updated lint. The lint gets quite noisy, bordering on unusable, and we of course lose some opportunities to emit errors, which I am concerned about. I wonder if we could silence the lint if there was at least one construction of the struct with default values... 🤔

estebank · 2026-09-26T16:20:18Z

Got concerned that not evaluating the const would cause arbitrary expressions through, but that is not the case:

warning: field `f` has a default value that is only checked when a value of `S` is constructed
 --> x.rs:4:12
  |
3 | struct S<T> {
4 |     f: T = { foo::<T>() },
  |            ^^^^^^^^^^^^^^ this can't be const-evaluated until use
  |
  = help: structs with type and const parameters only evaluate their default field values during construction, not eagerly when declared
  = note: `#[warn(unevaluated_default_field_value)]` on by default
help: if this behavior is acceptable, allow the lint and preferably write a test relying on the default value
  |
3 + #[expect(unevaluated_default_field_value)]
4 | struct S<T> {
  |

error[E0015]: cannot call non-const function `foo::<T>` in constants
 --> x.rs:4:14
  |
4 |     f: T = { foo::<T>() },
  |              ^^^^^^^^^^
  |
note: function `foo` is not const
 --> x.rs:6:1
  |
6 | fn foo<T>()->T { panic!()}
  | ^^^^^^^^^^^^^^
  = note: calls in constants are limited to constant functions, tuple structs and tuple variants

fmease

Thanks! I've got a couple of comments that need addressing, then I'll approve the PR after a re-review.

Could you update the PR title+description & squash away the outdated approach?

View changes since this review

fmease · 2026-10-04T18:06:02Z

        let variants = adt_def.variants();
        let packed = adt_def.repr().packed();
+        let own_params_require_monomorphization =
+            LazyCell::new(|| tcx.generics_of(item).own_requires_monomorphization());


Could you remove the LazyCell and perf it?

fmease · 2026-10-04T18:11:55Z

The changes in this file are no longer necessary under the new approach, right? Could you drop them again?

I feel like we should still be improving all const errors with the more targeted spans on the call that caused a whole const to fail, but reverting the change in this PR.

fmease · 2026-10-04T18:18:20Z

+    pub ban: u8 = panic!("asdf"),
+    // ^ If we run `const_eval_poly` without restricting const params, this would be
+    // evaluation panicked: asdf
+    // FIXME: This whould WARN!


Why doesn't it?

I suspect it is because the DefId of the default actually corresponds to the panic macro's crate (so non-local), which causes us not to have a HirId to attach the lint to.

Edit: almost, it was the Span instead, pointing inside the panic!. We have to use the call site instead.

fmease · 2026-10-04T18:19:02Z

+    //~^ ERROR attempt to compute `130_u8 + 130_u8`, which would overflow
 }

 pub struct Baz<const C: u8> {


If we deem it to spammy later on we can consider linting the type instead...

I'd looked into doing that. The issue I encountered was that we'd have to do some shenanigans with the hir id associated to the lint, make it be the whole item instead of allowing individual fields to be allowed. I'm sure we could work around it, but it was too involved to be part of an unrelated PR.

fmease · 2026-10-04T18:22:53Z

 struct Z<const X: usize> {
-    post_mono: usize = X / 0,
+    post_mono: usize = X / 0, //~ WARN
    //~^ ERROR attempt to divide `1_usize` by zero


Wait, this shouldn't get eval'ed post mono either.

The behavior should mirror our behavior for GCI:

//@ build-pass #![feature(generic_const_items)] const Z<const X: usize>: usize = X / 0;

You probably need to hunt down all other places in the compiler that evaluate field defaults and add the same own_requires_monomorphization checks there to achieve that.

Why shouldn't this error be emitted here? It triggers through indirect::<1>(); and let x: Z<1> = Z { .. };.

Side-note: we should have a better mechanism than ErrorHandled so that we can extend const errors with something akin to macro backtraces, instead of the free-floating notes we're using now.

fmease · 2026-10-04T18:31:03Z

+        ()
+            = { //~ WARN default value
+                f::<X>();
+                panic!(); //~ ERROR: explicit panic


This should only diverge post-mono since it's instantiated in main. I guess that's not the case yet (CC my other comment) but once it is, it should warrant a comment.

Wait, why isn't it correct for this panic to trigger at const eval when using Z { .. }?

…eric When trying to evaluate constants, if they reference const generics they will not be evaluated. When encountering this in default field values, emit a warn-by-default lint so that API designers are not caught of guard by this behavior. ``` warning: field `multiline_field` has a default value that is only checked when a value of `Z` is constructed --> $DIR/field-references-param-accurate-span.rs:8:15 | LL | struct Z<const X: usize> { LL | multiline_field: LL | () LL | = { | _______________^ LL | | f::<X>(); | | -------- this can't be const-evaluated until use LL | | panic!(); LL | | }, | |_____________^ unevaluated default value | = note: `#[warn(unevaluated_default_field_value)]` on by default help: if this behavior is acceptable, allow the lint and preferably write a test relying on the default value | LL + #[allow(unevaluated_default_field_value)] LL | struct Z<const X: usize> { | ``` Try spans better for `TooGeneric` errors. Support `Span` context in lints.

…resent when needed

…pes with generic params

rustbot · 2026-10-05T17:25:01Z

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.

estebank · 2026-10-06T00:42:50Z

@bors try @rust-timer queue

Always try to evaluate default field values and lint if it is too generic

rust-bors · 2026-10-06T01:44:24Z

☀️ Try build successful (CI)
Build commit: e741da4 (e741da44538220b14bec86cd7ee853c68ce544dd)
Base parent: ea13733 (ea137335b78829b4514bf1b4c16302f74fab8581)

rust-timer · 2026-10-06T02:53:42Z

Finished benchmarking commit (e741da4): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.6%, -0.1%]	10
Improvements ✅ (secondary)	-0.4%	[-0.7%, -0.1%]	43
All ❌✅ (primary)	-0.2%	[-0.6%, -0.1%]	10

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (primary -2.6%, secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.0%, 6.4%]	8
Improvements ✅ (primary)	-2.6%	[-2.6%, -2.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.6%	[-2.6%, -2.6%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 496.563s -> 492.175s (-0.88%)
Artifact size: 408.58 MiB -> 408.67 MiB (0.02%)

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 Sep 23, 2026

This comment was marked as outdated.

Sign in to view

estebank force-pushed the default-field-values-lint branch from d223a25 to 0e5fba6 Compare September 24, 2026 04:32

estebank marked this pull request as ready for review September 24, 2026 04:33

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 Sep 24, 2026

rustbot assigned mejrs Sep 24, 2026

This comment was marked as outdated.

Sign in to view

estebank commented Sep 24, 2026

View reviewed changes

fmease self-assigned this Sep 24, 2026

fmease 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 Sep 24, 2026

This comment has been minimized.

Sign in to view

estebank force-pushed the default-field-values-lint branch from f9acb05 to c6ed74c Compare October 4, 2026 14:27

This comment has been minimized.

Sign in to view

fmease unassigned mejrs Oct 4, 2026

fmease reviewed Oct 4, 2026

View reviewed changes

fmease added the F-default_field_values `#![feature(default_field_values)]` label Oct 4, 2026

fmease reviewed Oct 4, 2026

View reviewed changes

Comment thread compiler/rustc_hir_analysis/src/diagnostics.rs Outdated

estebank added 4 commits October 5, 2026 17:02

Suggest expect instead of allow, so that the annotation is only p…

282b810

…resent when needed

Use proposed strategy of never evaluating default field values for ty…

3000f74

…pes with generic params

review comments

1435c41

estebank force-pushed the default-field-values-lint branch from c6ed74c to 4b53cba Compare October 5, 2026 17:24

Update test comments

702470b

estebank force-pushed the default-field-values-lint branch from 4b53cba to 702470b Compare October 5, 2026 17:26

estebank added 3 commits October 5, 2026 17:36

Add more cases to test

1788cb4

Eager "requires mono" check

c9ed30f

Account for macro calls in default field values

4531f72

estebank 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 Oct 5, 2026

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 6, 2026

rust-bors Bot pushed a commit that referenced this pull request Oct 6, 2026

Auto merge of #163235 - estebank:default-field-values-lint, r=<try>

e741da4

Always try to evaluate default field values and lint if it is too generic

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 6, 2026

		if let Some(def_id) = field.value {
		if let Err(ErrorHandled::TooGeneric(span)) = tcx.const_eval_poly(def_id)

Uh oh!

Conversation

estebank commented Sep 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

rustbot commented Sep 24, 2026

Uh oh!

This comment was marked as outdated.

estebank left a comment • 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!

fmease Sep 24, 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!

fmease Sep 24, 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!

fmease Sep 24, 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!

fmease Sep 24, 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!

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!

estebank commented Sep 26, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

fmease left a comment • 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!

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!

estebank Oct 5, 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!

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!

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

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

estebank commented Sep 23, 2026 •

edited

Loading

estebank left a comment •

edited by rustbot

Loading

fmease Sep 24, 2026 •

edited

Loading

fmease Sep 24, 2026 •

edited

Loading

fmease Sep 24, 2026 •

edited

Loading

fmease Sep 24, 2026 •

edited

Loading

fmease left a comment •

edited by rustbot

Loading

estebank Oct 5, 2026 •

edited

Loading

estebank Oct 6, 2026 •

edited

Loading