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

fmease · 2025-06-10T12:26:36Z

Part of #113521.

fmease · 2025-06-10T12:26:57Z

@bors2 try @rust-timer queue

rust-bors · 2025-06-10T12:27:01Z

⌛ Trying commit 74ec3ea with merge 4151b9a…

To cancel the try build, run the command @bors2 try cancel.

[early rough draft] GCI: Don't evaluate free const items with impossible predicates

compiler/rustc_passes/src/reachable.rs

BoxyUwU

We should consider moving all of these call-site checks into ctfe itself, e.g. eval_to_const_value_raw_provider. This wont affect const patterns which go through _for_typeck versions of the CTFE entry points.

I also then think that the impossible predicates check in that place should ICE on predicates containing non region params as that shouldn't be reachable (and if it is, then we're evaluating generic constants in places we might not want to be).

compiler/rustc_passes/src/reachable.rs

rust-bors · 2025-06-10T14:52:25Z

☀️ Try build successful (CI)
Build commit: 4151b9a (4151b9aaad261468f4260336981f34de2f05df15)

rust-timer · 2025-06-11T04:13:10Z

Finished benchmarking commit (4151b9a): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

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

Max RSS (memory usage)

Results (primary -5.1%, secondary -2.1%)

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)	3.5%	[3.5%, 3.5%]	1
Improvements ✅ (primary)	-5.1%	[-9.4%, -3.0%]	6
Improvements ✅ (secondary)	-2.3%	[-4.3%, -1.1%]	21
All ❌✅ (primary)	-5.1%	[-9.4%, -3.0%]	6

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: 753.145s -> 753.291s (0.02%)
Artifact size: 372.18 MiB -> 372.22 MiB (0.01%)

fmease · 2025-06-24T12:46:41Z

Cargo.lock

I also then think that the impossible predicates check in that place should ICE on predicates containing non region params as that shouldn't be reachable (and if it is, then we're evaluating generic constants in places we might not want to be).

Adding debug_assert!(!predicates.has_non_region_param()); to fn impossible_predicates, lead to a whole slew of test failures (I didn't complete the test run). E.g.,

Some failing tests

tests/ui/associated-consts/associated-const-marks-live-code.rs tests/ui/async-await/async-fn-size-moved-locals.rs tests/ui/async-await/async-fn-size-uninit-locals.rs tests/ui/async-await/repeat_count_const_in_async_fn.rs tests/ui/binding/match-arm-statics.rs tests/ui/const_prop/ice-issue-96944.rs tests/ui/consts/const-autoderef.rs tests/ui/consts/chained-constants-stackoverflow.rs tests/ui/consts/const-blocks/const-repeat.rs tests/ui/consts/const-const.rs tests/ui/consts/const-enum-cast.rs tests/ui/consts/const-eval/strlen.rs tests/ui/consts/const-expr-in-fixed-length-vec.rs tests/ui/consts/const-expr-in-vec-repeat.rs tests/ui/consts/const-fn-method.rs tests/ui/consts/const-trait-to-trait.rs tests/ui/consts/ice-48279.rs tests/ui/consts/min_const_fn/min_const_fn_libstd.rs tests/ui/consts/offset_from.rs tests/ui/consts/ptr_comparisons.rs tests/ui/consts/ptr_is_null.rs

Adding debug_assert!(!predicates.has_non_region_param()); to fn impossible_predicates

I was wrong about that, it's actually completely fine 🤦 I must've had some other changes in the working tree... Sry bout the miscommunication there

fmease · 2025-06-24T12:52:16Z

compiler/rustc_passes/src/reachable.rs

We should consider moving all of these call-site checks into ctfe itself, e.g. eval_to_const_value_raw_provider. This wont affect const patterns which go through _for_typeck versions of the CTFE entry points.

As discussed, long term, that would be the way to go. However, it makes me uncomfortable that eval_to_const_value_raw has so many transitive callers which I wasn't yet able to audit entirely. I know that you told me that this function should be safe to modify from a soundness perspective and you're probably right, I just haven't finished tracing the entire caller graph. WIP:

Caller graph (X called by Y)

+ eval_to_const_value_raw [eval_to_const_value_raw_provider] (???) +-- check_crate/par_hir_body_owners/DefKind::Const (OK) +-- const_eval_global_id (???) +-- eval_intrinsic (OK) +-- const_eval_poly (OK) | +-- codegen_global_asm (OK) | +-- check_type_defn/variants/fields [default_field_values] (OK) | +-- check_type_defn/ty::VariantDiscr::Explicit (OK) | +-- eval_explicit_discr (OK) | +-- monomorphize/RootCollector/process_item/DefKind::Const (OK) +-- const_eval_resolve (???) | +-- Const::eval (???) | +-- eval_mir_constant (???) | | +... [~20 call sites] (TODO) | +-- inline_to_global_operand/InlineAsmOperand::Const (OK) | +-- push_stack_frame_raw/body.required_consts() (???) | +-- try_eval_scalar... (TODO) | +-- MIR transform/simplify_repeated_aggregate (???) | +-- eval_constant (???) | +-- eval_operand... (TODO) | +-- MIR transform/ConstPropagator/visit_const_operand (???) | +-- collect_items_of_instance/body.requires_consts() (???) +-- const_eval_instance (???) +-- codegen_regular_intrinsic_call (OK) +-- codegen_intrinsic_call (OK) +-- eval_instance (???) +-- try_const_eval [SMIR] (???)

(As an aside, even if we enriched eval_to_const_value_raw_provider with a call to impossible_predicates, here in mod reachable it would be of no use to us as it uses const_eval_poly_to_alloc which doesn't depend on that function)

fmease · 2025-06-24T13:20:56Z

Mono collector now uses instantiate_and_check_impossible_predicates which filters out predicates with early-bound regions contrary to impossible_predicates, so might have a mismatch in behavior between mono collection, reachability analysis and typeck which seems problematic but I haven't thought about it any further (does IACIP assume erased lifetimes?).

Despite that, imma recheck perf cuz I removed the predicates.is_empty() "micro opt".
@bors2 try @rust-timer queue

[early rough draft] GCI: Don't evaluate free const items with impossible predicates

rust-bors · 2025-06-24T13:21:01Z

⌛ Trying commit 380088d with merge 10bc814…

To cancel the try build, run the command @bors2 try cancel.

BoxyUwU · 2025-06-24T13:48:23Z

compiler/rustc_monomorphize/src/collector.rs

+                if !self.tcx.generics_of(def_id).own_requires_monomorphization()
+                    && !self.tcx.instantiate_and_check_impossible_predicates((
+                        def_id,
+                        ty::GenericArgs::identity_for_item(self.tcx, def_id),


this should probably just copy the logic from DefKind::Enum/Struct/Union for checking impossible preds and constructing identity args

The const item branch now copies the relevant parts of the ADT branch 👍

BoxyUwU · 2025-06-24T13:49:57Z

compiler/rustc_hir_analysis/src/lib.rs

+                let predicates = tcx.predicates_of(item_def_id);
+                let predicates = predicates.instantiate_identity(tcx).predicates;
+
+                // FIXME(fmease): May its result be 'incorrect' if the preds have ReEarlyBound?


Yeah I think you should be able to construct a case where an impossible pred isnt found due to a lifetime parameter. E.g. const _: usize where for<'b> [&'a u8]: Sized = ... probably will get evaluated unless you erase regions

We're now erasing in mono collector and as a consequence we no longer eval the initializer in your example 👍

BoxyUwU · 2025-06-24T13:50:26Z

compiler/rustc_hir_analysis/src/lib.rs

+
+                // FIXME(fmease): May its result be 'incorrect' if the preds have ReEarlyBound?
+                if !traits::impossible_predicates(tcx, predicates) {
+                    // FIXME(generic_const_items): Passing empty instead of identity args is fishy but


this should be fixed yeah 🤔 I don't think ctfe should have to handle there being instances with wrong args

Right, we should. If you're okay with it, I'd prefer to address this in a separate PR because this is super perf sensitive.

This used to be a call to fn const_eval_poly for the longest time which used to construct identity args etc. After a reshuffle (#121087), it was changed to the current no-args fully-mono version (#121387) to fix perf. Maybe the identity vs. no args isn't mega perf sensitive and it's paramenv norm that's the culprit but in #136429 I also did some tests, so it's unclear.

E.g., ea1cdda (perf results: #136429 (comment)) and 6f11489 (perf results: #136429 (comment)). Ofc, they also include unrelated changes to WF-check, so the results are skewed.

rust-bors · 2025-06-24T15:51:51Z

☀️ Try build successful (CI)
Build commit: 10bc814 (10bc814a261100b40f7fa5feaa6a079876607337, parent: e4b9d0141fdd210fcceebd2b67f7be113401c461)

rust-bors · 2025-06-25T20:04:26Z

⌛ Trying commit 0e9126c with merge cea506b…

To cancel the try build, run the command @bors2 try cancel.

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

rust-bors · 2025-06-25T22:37:55Z

☀️ Try build successful (CI)
Build commit: cea506b (cea506b6d4e9d59bbdaea6b74051c551246bff6d, parent: e4b9d0141fdd210fcceebd2b67f7be113401c461)

rust-timer · 2025-06-26T01:10:48Z

Finished benchmarking commit (cea506b): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@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.7%	[0.3%, 1.0%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.3%, 1.0%]	8

Max RSS (memory usage)

Results (primary 2.3%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[1.7%, 2.9%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.3%	[1.7%, 2.9%]	2

Cycles

Results (secondary -3.6%)

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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.6%	[-4.1%, -3.0%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 690.402s -> 687.107s (-0.48%)
Artifact size: 372.03 MiB -> 371.92 MiB (-0.03%)

fmease · 2025-07-02T16:16:44Z

PR #142893 (which conflicted with this PR / made it unmergeable) heavily affected perf. Thus I'm now retrying if this PR is still sensitive.

@bors2 try @rust-timer queue

rust-bors · 2025-07-02T16:16:48Z

⌛ Trying commit 8d3bc94 with merge 41283df…

To cancel the try build, run the command @bors2 try cancel.

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

rust-bors · 2025-07-02T18:32:17Z

☀️ Try build successful (CI)
Build commit: 41283df (41283df7b958f7c986dcf1d3920b6896ab276564, parent: b94bd12401d26ccf1c3b04ceb4e950b0ff7c8d29)

rust-timer · 2025-07-03T08:41:55Z

Finished benchmarking commit (41283df): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

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

Max RSS (memory usage)

Results (primary 0.4%)

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

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

Cycles

Results (primary -1.5%, secondary 8.2%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[2.3%, 2.3%]	1
Regressions ❌ (secondary)	8.2%	[0.7%, 13.3%]	10
Improvements ✅ (primary)	-2.7%	[-5.1%, -1.0%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.5%	[-5.1%, 2.3%]	4

Binary size

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

Bootstrap: 462.452s -> 460.902s (-0.34%)
Artifact size: 372.20 MiB -> 372.15 MiB (-0.01%)

fmease · 2025-07-03T15:52:42Z

compiler/rustc_hir_analysis/src/lib.rs

+
+                // FIXME(fmease): May its result be 'incorrect' if the preds have ReEarlyBound?
+                if !traits::impossible_predicates(tcx, predicates) {
+                    // FIXME(generic_const_items): Passing empty instead of identity args is fishy but


Right, we should. If you're okay with it, I'd prefer to address this in a separate PR because this is super perf sensitive.

This used to be a call to fn const_eval_poly for the longest time which used to construct identity args etc. After a reshuffle (#121087), it was changed to the current no-args fully-mono version (#121387) to fix perf. Maybe the identity vs. no args isn't mega perf sensitive and it's paramenv norm that's the culprit but in #136429 I also did some tests, so it's unclear.

E.g., ea1cdda (perf results: #136429 (comment)) and 6f11489 (perf results: #136429 (comment)). Ofc, they also include unrelated changes to WF-check, so the results are skewed.

fmease · 2025-07-03T15:53:22Z

compiler/rustc_middle/src/mir/interpret/queries.rs

+    /// Evaluates a constant without providing any generic parameters.
+    ///
+    /// This is useful to evaluate consts that can't take any generic arguments like enum
+    /// discriminants. If a non-region generic parameter is used within the constant


(apart splitting of the synopsis / introductory paragraph, here & below I changed generic parameter to non-region generic parameter and dropped the mention of const items since they can be generic, GCI duh)

fmease · 2025-07-03T15:55:07Z

compiler/rustc_hir_analysis/src/lib.rs

+                let predicates = tcx.predicates_of(item_def_id);
+                let predicates = predicates.instantiate_identity(tcx).predicates;
+
+                // FIXME(fmease): May its result be 'incorrect' if the preds have ReEarlyBound?


We're now erasing in mono collector and as a consequence we no longer eval the initializer in your example 👍

fmease · 2025-07-03T15:56:23Z

compiler/rustc_monomorphize/src/collector.rs

+                if !self.tcx.generics_of(def_id).own_requires_monomorphization()
+                    && !self.tcx.instantiate_and_check_impossible_predicates((
+                        def_id,
+                        ty::GenericArgs::identity_for_item(self.tcx, def_id),


The const item branch now copies the relevant parts of the ADT branch 👍

fmease · 2025-07-03T16:02:54Z

compiler/rustc_monomorphize/src/collector.rs

+                if tcx.generics_of(def_id).own_requires_monomorphization() {
+                    return;
+                }
+                let args = ty::GenericArgs::for_item(tcx, def_id, |param, _| {
+                    expect_and_erase_regions(tcx, param)
+                });
+                if tcx.instantiate_and_check_impossible_predicates((def_id, args)) {
+                    return;
                }


This pattern occurs 3 times in this file: For ADTs, const items and impl blocks. However, I was unable to extract the code into a meaningful function. The only thing I was able to come up with was sth. like:

fn instantiate_erasing_regions_if_monomorphic_enough_and_check_impossible_predicates<'tcx>( tcx: TyCtxt<'tcx>, def_id: DefId, ) -> Option<ty::GenericArgs<'tcx>> { if !tcx.generics_of(def_id).requires_monomorphization(tcx) && let args = ty::GenericArgs::for_item(tcx, def_id, |param, _| expect_and_erase_regions(tcx, param)) && !tcx.instantiate_and_check_impossible_predicates((def_id, args)) { return Some(args); } None }

and my eyes started bleeding 🩸🩸🩸

fmease · 2025-07-03T16:10:21Z

Cargo.lock

Adding debug_assert!(!predicates.has_non_region_param()); to fn impossible_predicates

I was wrong about that, it's actually completely fine 🤦 I must've had some other changes in the working tree... Sry bout the miscommunication there

rustbot · 2025-07-03T16:13:25Z

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

fmease · 2025-07-03T16:13:29Z

@rustbot review

RalfJung · 2025-07-03T16:17:01Z

compiler/rustc_hir_analysis/src/lib.rs

@@ -238,12 +238,18 @@ pub fn check_crate(tcx: TyCtxt<'_>) {
                check::maybe_check_static_with_link_section(tcx, item_def_id);
            }
            DefKind::Const if !tcx.generics_of(item_def_id).own_requires_monomorphization() => {


I would expect !own_requires_monomorphization means there are no generics to begin with? Or what does that function mean? It is sadly undocumented...

It does not make sense to me that we'd ever evaluate a generic free const item. How would we even pick the instance for the generic parameters...?

Ah, there was #136429 which I already forgot about. IMO the obvious fix is to just revert that PR...

... but I guess that wouldn't even be enough since even non-generic consts can have where clauses. Right. Uh, we may have to just skip all of those?

own_requires_monomorphization is synonymous with "has non-region generic params" meaning we do eval lifetime-generic const exprs (more precisely early-bound-lifetime-generic).

How would we even pick the instance for the generic parameters...?

That's obviously fine since we're only dealing with lifetime params since trait resolution etc. happens modulo non-late-bound regions / most if not all regions get fully erased. No problem there.

RalfJung · 2025-07-03T16:23:55Z

compiler/rustc_hir_analysis/src/lib.rs

+                let predicates = tcx.predicates_of(item_def_id);
+                let predicates = predicates.instantiate_identity(tcx).predicates;
+
+                if !traits::impossible_predicates(tcx, predicates) {


Is it guaranteed that !impossible means "possible"? Or at least, does the contract for impossible_predicates imply that a predicate considered "possible" will not ICE later when one does normal type system things and makes basic assumptions about primitive MIR ops, sizedness, and things like that?

(I feel I asked @BoxyUwU that same question already earlier this year in a different context and the answer was "yes it's fine", but I'm not sure...)

Unfortunately I can't answer that with 100% confidence since I'm not super familiar with the innards and all the little details of const eval.

I know that layout computation has been made more robust against that somewhat recently but I'm not sure about the rest.

I know that the MIR pass ImpossiblePredicates replaces MIR bodies with Unreachable¹ if the body has unsatisfiable ("trivially unsatisfied") global² predicates. However, I don't actually know how early that pass gets run (and it doesn't affect e.g., layout computation unless I'm totally off base).

It's certainly a valid question and I need to have researched that before opening the RFC. Tho if my tired brain doesn't trick me right now, my change should in theory eliminate potential ICEs rather than introducing new ones because we eval less.

Footnotes

These actually trigger during const eval on master. ↩

Meaning it disagrees with the 3 checks I've added in this PR when there are predicates containing ReEarlyBound (erasing wouldn't help because ReErased also turns a predicate non-global). My new checks should be stricter than the one used during said MIR pass, so that shouldn't be problematic (or at least not more problematic compared to master). ↩

my change should in theory eliminate potential ICEs rather than introducing new ones because we eval less.
Footnotes

Yeah, definitely. I was just wondering if it evals less enough. ;)

fmease added this to Generic Const Items (GCI) Jun 10, 2025

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

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 10, 2025

fmease changed the title ~~[early rough draft] GCI: Don't evaluate the free const items with impossible predicates~~ [early rough draft] GCI: Don't evaluate free const items with impossible predicates Jun 10, 2025

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Jun 10, 2025

Auto merge of #142293 - fmease:gci-dont-eval-the-impossible, r=<try>

4151b9a

[early rough draft] GCI: Don't evaluate free const items with impossible predicates

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 10, 2025

fmease moved this to In Progress in Generic Const Items (GCI) Jun 10, 2025

This comment was marked as off-topic.

Sign in to view

fmease added the rla-silenced Silences rust-log-analyzer postings to the PR it's added on. label Jun 10, 2025

BoxyUwU self-assigned this Jun 10, 2025

fmease commented Jun 10, 2025

View reviewed changes

compiler/rustc_passes/src/reachable.rs Show resolved Hide resolved

BoxyUwU reviewed Jun 10, 2025

View reviewed changes

compiler/rustc_passes/src/reachable.rs Outdated Show resolved Hide resolved

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 Jun 11, 2025

fmease commented Jun 24, 2025

View reviewed changes

fmease force-pushed the gci-dont-eval-the-impossible branch 2 times, most recently from 498b2e2 to 380088d Compare June 24, 2025 13:08

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Jun 24, 2025

Auto merge of #142293 - fmease:gci-dont-eval-the-impossible, r=<try>

10bc814

[early rough draft] GCI: Don't evaluate free const items with impossible predicates

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 24, 2025

BoxyUwU reviewed Jun 24, 2025

View reviewed changes

rust-bors bot added a commit that referenced this pull request Jun 25, 2025

Auto merge of #142293 - fmease:gci-dont-eval-the-impossible, r=<try>

cea506b

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

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 25, 2025

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 Jun 26, 2025

This comment was marked as resolved.

Sign in to view

bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 27, 2025

fmease force-pushed the gci-dont-eval-the-impossible branch from 0e9126c to 8d3bc94 Compare July 2, 2025 16:13

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Jul 2, 2025

Auto merge of #142293 - fmease:gci-dont-eval-the-impossible, r=<try>

41283df

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

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 2, 2025

This comment has been minimized.

Sign in to view

rustbot removed S-waiting-on-perf Status: Waiting on a perf run to be completed. perf-regression Performance regression. labels Jul 3, 2025

fmease force-pushed the gci-dont-eval-the-impossible branch from 8d3bc94 to 569f3a3 Compare July 3, 2025 15:36

GCI: Don't evaluate free const items with impossible predicates

3cddea4

fmease force-pushed the gci-dont-eval-the-impossible branch from 569f3a3 to 3cddea4 Compare July 3, 2025 16:08

fmease commented Jul 3, 2025

View reviewed changes

fmease marked this pull request as ready for review July 3, 2025 16:13

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 3, 2025

RalfJung reviewed Jul 3, 2025

View reviewed changes

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

Are you sure you want to change the base?

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

Conversation

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

Uh oh!

Uh oh!

fmease commented Jun 10, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jun 10, 2025

Uh oh!

This comment was marked as off-topic.

Uh oh!

BoxyUwU left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rust-bors bot commented Jun 10, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jun 11, 2025

Overall result: no relevant changes - no action needed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Jun 24, 2025 • 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!

fmease commented Jun 24, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jun 24, 2025

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors bot commented Jun 24, 2025

Uh oh!

rust-bors bot commented Jun 25, 2025

Uh oh!

rust-bors bot commented Jun 25, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jun 26, 2025

Overall result: ❌ regressions - please read the text below

Uh oh!

This comment was marked as resolved.

fmease commented Jul 2, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jul 2, 2025

Uh oh!

rust-bors bot commented Jul 2, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jul 3, 2025

Overall result: no relevant changes - no action needed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Jul 3, 2025 • 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

fmease commented Jun 10, 2025 •

edited

Loading

fmease Jun 24, 2025 •

edited

Loading

fmease Jul 3, 2025 •

edited

Loading

fmease Jul 3, 2025 •

edited

Loading

fmease Jul 3, 2025 •

edited

Loading

RalfJung Jul 3, 2025 •

edited

Loading

fmease Jul 3, 2025 •

edited

Loading