GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants#136429

fmease · 2025-02-02T10:44:18Z

1st commit: Partially addresses #136204 by turning const eval errors from post to pre-mono for free lifetime-generic constants.
- As the linked issue/comment states, on master there's a difference between const _: () = panic!(); (pre-mono error) and const _<'a>: () = panic!(); (post-mono error) which feels wrong.
- With this PR, both become pre-mono ones!
2nd commit: Oof, yeah, I missed that in the initial impl!

This doesn't fully address #136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is const _UNUSED: () = () where for<'_delay> String: Copy; which can also be found over at the tracking issue #113521.

r? compiler-errors or reassign

compiler/rustc_hir_analysis/src/lib.rs

fmease · 2025-02-02T10:45:58Z

@bors try @rust-timer queue

bors · 2025-02-02T10:47:10Z

⌛ Trying commit 5a8ee9b with merge ea1cdda...

GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants 1st commit: Partially addresses rust-lang#136204 by turning const eval errors from post to pre-mono for free lifetime-generic constants. Re. 2nd commit: Oof, that's embarrassing! How could I miss that in the initial impl? This doesn't fully address rust-lang#136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `#![feature(trivial_bounds)] const _UNUSED: () = () where String: Copy;` which can also be found over at the tracking issue rust-lang#113521. r? compiler-errors or reassign

tests/ui/generic-const-items/def-site-predicates-wf.rs

bors · 2025-02-02T12:36:23Z

☀️ Try build successful - checks-actions
Build commit: ea1cdda (ea1cdda3b51a1290675800f2196813f4bfc693bd)

rust-timer · 2025-02-02T13:54:03Z

Finished benchmarking commit (ea1cdda): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.4%, 1.1%]	8
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.9%	[0.4%, 1.1%]	8

Max RSS (memory usage)

Results (primary 1.5%, secondary -2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.5%	[1.0%, 2.0%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.0%, -2.0%]	1
All ❌✅ (primary)	1.5%	[1.0%, 2.0%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 777.275s -> 776.801s (-0.06%)
Artifact size: 328.69 MiB -> 328.73 MiB (0.01%)

compiler/rustc_hir_analysis/src/check/wfcheck.rs

rustbot · 2025-02-03T04:27:00Z

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @rust-lang/wg-const-eval

fmease · 2025-02-03T04:37:11Z

@bors try @rust-timer queue

GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants 1st commit: Partially addresses rust-lang#136204 by turning const eval errors from post to pre-mono for free lifetime-generic constants. Re. 2nd commit: Oof, yeah, I missed that in the initial impl! This doesn't fully address rust-lang#136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `#![feature(trivial_bounds)] const _UNUSED: () = () where String: Copy;` which can also be found over at the tracking issue rust-lang#113521. r? compiler-errors or reassign

bors · 2025-02-03T04:38:22Z

⌛ Trying commit 9f2fdff with merge 6f11489...

bors · 2025-02-03T06:28:05Z

☀️ Try build successful - checks-actions
Build commit: 6f11489 (6f11489377389dbe08c91408f1c8f953933c18cd)

RalfJung · 2025-02-03T07:57:05Z

turning const eval errors from post to pre-mono for free lifetime-generic constants.

This should be listed as an item in the tracking issue to make sure it is discussed during stabilization.

fmease · 2025-05-27T17:27:28Z

Oh no :( @bors r-

fmease · 2025-05-28T13:27:28Z

Right, in #140672 errs made us deeply normalize during WF in the next solver which didn't get picked up as a conflict during the rebase (good that a test caught it!). Fixed.

@bors r=BoxyUwU

bors · 2025-05-28T13:27:31Z

📌 Commit 9f12748 has been approved by BoxyUwU

It is now in the queue for this repository.

Rollup of 16 pull requests Successful merges: - #136429 (GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants) - #138139 (Emit warning while outputs is not exe and prints linkage info) - #141104 (Test(fs): Fix `test_eq_windows_file_type` for Windows 7) - #141477 (Path::with_extension: show that it adds an extension where one did no…) - #141533 (clean up old rintf leftovers) - #141612 (Call out possibility of invariant result in variance markers) - #141638 (Use `builtin_index` instead of hand-rolling it) - #141643 (ci: verify that codebuild jobs use ghcr.io) - #141675 (Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.) - #141680 (replace TraitRef link memory.md) - #141682 (interpret/allocation: Fixup type for `alloc_bytes`) - #141683 (Handle ed2021 precise capturing of unsafe binder) - #141684 (rustbook: Bump versions of `onig` and `onig_sys`) - #141687 (core: unstably expose atomic_compare_exchange so stdarch can use it) - #141690 (Add `rustc_diagnostic_item` to `sys::Mutex` methods) - #141702 (Add eholk to compiler reviewer rotation) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #136429 - fmease:gci-fix-def-site-checks, r=BoxyUwU GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants * 1st commit: Partially addresses [#136204](#136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants. * As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong. * With this PR, both become pre-mono ones! * 2nd commit: Oof, yeah, I missed that in the initial impl! This doesn't fully address #136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue #113521. r? compiler-errors or reassign

Rollup of 16 pull requests Successful merges: - rust-lang/rust#136429 (GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants) - rust-lang/rust#138139 (Emit warning while outputs is not exe and prints linkage info) - rust-lang/rust#141104 (Test(fs): Fix `test_eq_windows_file_type` for Windows 7) - rust-lang/rust#141477 (Path::with_extension: show that it adds an extension where one did no…) - rust-lang/rust#141533 (clean up old rintf leftovers) - rust-lang/rust#141612 (Call out possibility of invariant result in variance markers) - rust-lang/rust#141638 (Use `builtin_index` instead of hand-rolling it) - rust-lang/rust#141643 (ci: verify that codebuild jobs use ghcr.io) - rust-lang/rust#141675 (Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.) - rust-lang/rust#141680 (replace TraitRef link memory.md) - rust-lang/rust#141682 (interpret/allocation: Fixup type for `alloc_bytes`) - rust-lang/rust#141683 (Handle ed2021 precise capturing of unsafe binder) - rust-lang/rust#141684 (rustbook: Bump versions of `onig` and `onig_sys`) - rust-lang/rust#141687 (core: unstably expose atomic_compare_exchange so stdarch can use it) - rust-lang/rust#141690 (Add `rustc_diagnostic_item` to `sys::Mutex` methods) - rust-lang/rust#141702 (Add eholk to compiler reviewer rotation) r? `@ghost` `@rustbot` modify labels: rollup

@BoxyUwU

GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (rust-lang#136168 & rust-lang#136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example. The closed PR rust-lang#142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue. Follow up to rust-lang#136168 & rust-lang#136429. Partially supersedes rust-lang#142293. Part of rust-lang#113521. r? @BoxyUwU

@BoxyUwU

GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (rust-lang#136168 & rust-lang#136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example. The closed PR rust-lang#142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue. Follow up to rust-lang#136168 & rust-lang#136429. Partially supersedes rust-lang#142293. Part of rust-lang#113521. r? @BoxyUwU

@BoxyUwU

GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (rust-lang#136168 & rust-lang#136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example. The closed PR rust-lang#142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue. Follow up to rust-lang#136168 & rust-lang#136429. Partially supersedes rust-lang#142293. Part of rust-lang#113521. r? @BoxyUwU

@BoxyUwU

GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (rust-lang#136168 & rust-lang#136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example. The closed PR rust-lang#142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue. Follow up to rust-lang#136168 & rust-lang#136429. Partially supersedes rust-lang#142293. Part of rust-lang#113521. r? @BoxyUwU

@BoxyUwU

Rollup merge of #153269 - fmease:gci-reach-no-eval, r=BoxyUwU GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (#136168 & #136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example. The closed PR #142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue. Follow up to #136168 & #136429. Partially supersedes #142293. Part of #113521. r? @BoxyUwU

@BoxyUwU

GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (rust-lang/rust#136168 & rust-lang/rust#136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example. The closed PR rust-lang/rust#142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue. Follow up to rust-lang/rust#136168 & rust-lang/rust#136429. Partially supersedes rust-lang/rust#142293. Part of rust-lang/rust#113521. r? @BoxyUwU

fmease added the F-generic_const_items `#![feature(generic_const_items)]` label Feb 2, 2025

rustbot assigned compiler-errors Feb 2, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 2, 2025

fmease commented Feb 2, 2025

View reviewed changes

compiler/rustc_hir_analysis/src/lib.rs Outdated Show resolved Hide resolved

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 Feb 2, 2025

fmease commented Feb 2, 2025

View reviewed changes

tests/ui/generic-const-items/def-site-predicates-wf.rs Outdated Show resolved Hide resolved

tests/ui/generic-const-items/def-site-predicates-wf.rs Show resolved Hide resolved

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Feb 2, 2025

compiler-errors reviewed Feb 2, 2025

View reviewed changes

compiler/rustc_hir_analysis/src/check/wfcheck.rs Outdated Show resolved Hide resolved

fmease force-pushed the gci-fix-def-site-checks branch from 5a8ee9b to 1dc3d6e Compare February 3, 2025 04:26

fmease force-pushed the gci-fix-def-site-checks branch from 1dc3d6e to 9c2b71a Compare February 3, 2025 04:27

fmease marked this pull request as draft February 3, 2025 04:28

fmease force-pushed the gci-fix-def-site-checks branch from 9c2b71a to 9f2fdff Compare February 3, 2025 04:36

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 Feb 3, 2025

This comment has been minimized.

Sign in to view

fmease added perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. and removed perf-regression Performance regression. labels May 27, 2025

This comment has been minimized.

Sign in to view

bors 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 May 27, 2025

GCI: Check where-clauses for well-formedness at the def site

9f12748

fmease force-pushed the gci-fix-def-site-checks branch from fa6cd85 to 9f12748 Compare May 28, 2025 13:23

bors 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 May 28, 2025

jhpratt mentioned this pull request May 29, 2025

Rollup of 16 pull requests #141716

Merged

bors merged commit d3c605a into rust-lang:master May 29, 2025
7 checks passed

github-project-automation bot moved this from In Progress to Done in Generic Const Items (GCI) May 29, 2025

rustbot added this to the 1.89.0 milestone May 29, 2025

fmease deleted the gci-fix-def-site-checks branch May 29, 2025 08:53

fmease mentioned this pull request Jul 3, 2025

GCI: Don't evaluate the initializer of free const items that have trivially unsatisfied predicates #142293

Closed

fmease mentioned this pull request Aug 27, 2025

Presence of lifetime params on free consts shouldn't affect evaluatability & impossible preds should prevent evaluation #136204

Closed

fmease mentioned this pull request Mar 2, 2026

GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items #153269

Merged

Uh oh!

Conversation

fmease commented Feb 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

fmease commented Feb 2, 2025

Uh oh!

This comment has been minimized.

bors commented Feb 2, 2025

Uh oh!

Uh oh!

Uh oh!

bors commented Feb 2, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Feb 2, 2025

Overall result: ❌ regressions - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Uh oh!

rustbot commented Feb 3, 2025

Uh oh!

fmease commented Feb 3, 2025

Uh oh!

This comment has been minimized.

bors commented Feb 3, 2025

Uh oh!

bors commented Feb 3, 2025

Uh oh!

This comment has been minimized.

RalfJung commented Feb 3, 2025 via email

Uh oh!

This comment has been minimized.

fmease commented May 27, 2025

Uh oh!

fmease commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented May 28, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

fmease commented Feb 2, 2025 •

edited

Loading

fmease commented May 28, 2025 •

edited

Loading