gce: don't ICE on non-local const#143106
Merged
bors merged 1 commit intorust-lang:masterfrom Jun 28, 2025
Merged
Conversation
This comment has been minimized.
This comment has been minimized.
a912dcf to
0e32036
Compare
Collaborator
|
This PR changes a file inside |
Member
Yep! I think this change is correct though. Thanks for making this PR @bors r+ rollup |
Collaborator
bors
added a commit
that referenced
this pull request
Jun 27, 2025
Rollup of 9 pull requests Successful merges: - #139858 (New const traits syntax) - #140809 (Reduce special casing for the panic runtime) - #142730 (suggest declaring modules when file found but module not defined) - #142806 (Normalize before computing ConstArgHasType goal in new solver) - #143046 (const validation: properly ignore zero-sized UnsafeCell) - #143092 (const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology) - #143096 (tag_for_variant: properly pass TypingEnv) - #143104 (hir_analysis: prohibit `dyn PointeeSized`) - #143106 (gce: don't ICE on non-local const) Failed merges: - #143036 (Remove support for `dyn*` from the compiler) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Jun 28, 2025
Rollup merge of #143106 - yotamofek:pr/gce/non-local-ice, r=BoxyUwU gce: don't ICE on non-local const Fixes #133808 I have absolutely no idea what I'm doing here, but I followed `@BoxyUwU` 's [instructions](#133808 (comment)), and turns out this small change fixes #133808, and doesn't seem to break anything else. (This code path is only reachable when the GCE feature gate is enabled, so even if it does break in a way that is not caught by current test coverage, I guess it's not as bad as breaking stable or non-incomplete features?) Anyways, r? `@BoxyUwU` , if you don't mind.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Jun 28, 2025
Rollup of 9 pull requests Successful merges: - rust-lang/rust#139858 (New const traits syntax) - rust-lang/rust#140809 (Reduce special casing for the panic runtime) - rust-lang/rust#142730 (suggest declaring modules when file found but module not defined) - rust-lang/rust#142806 (Normalize before computing ConstArgHasType goal in new solver) - rust-lang/rust#143046 (const validation: properly ignore zero-sized UnsafeCell) - rust-lang/rust#143092 (const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology) - rust-lang/rust#143096 (tag_for_variant: properly pass TypingEnv) - rust-lang/rust#143104 (hir_analysis: prohibit `dyn PointeeSized`) - rust-lang/rust#143106 (gce: don't ICE on non-local const) Failed merges: - rust-lang/rust#143036 (Remove support for `dyn*` from the compiler) r? `@ghost` `@rustbot` modify labels: rollup
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Jul 10, 2025
Rollup of 9 pull requests Successful merges: - rust-lang/rust#139858 (New const traits syntax) - rust-lang/rust#140809 (Reduce special casing for the panic runtime) - rust-lang/rust#142730 (suggest declaring modules when file found but module not defined) - rust-lang/rust#142806 (Normalize before computing ConstArgHasType goal in new solver) - rust-lang/rust#143046 (const validation: properly ignore zero-sized UnsafeCell) - rust-lang/rust#143092 (const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology) - rust-lang/rust#143096 (tag_for_variant: properly pass TypingEnv) - rust-lang/rust#143104 (hir_analysis: prohibit `dyn PointeeSized`) - rust-lang/rust#143106 (gce: don't ICE on non-local const) Failed merges: - rust-lang/rust#143036 (Remove support for `dyn*` from the compiler) r? `@ghost` `@rustbot` modify labels: rollup
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Feb 6, 2026
…e-consts, r=BoxyUwU
MGCA: require #[type_const] on free consts too
When investigating another issue, I discovered that following ICEs (the `const_of_item` query doesn't support non-type_const-marked constants and does a `span_delayed_bug`):
```rust
#![feature(min_generic_const_args)]
#![allow(incomplete_features)]
const N: usize = 4;
fn main() {
let x = [(); N];
}
```
My initial thought of "only require `#[type_const]` on places that stable doesn't currently accept" ran into the issue of this compiling on stable today:
```rust
trait Trait {
const N: usize;
}
impl<const PARAM: usize> Trait for [(); PARAM] {
const N: usize = PARAM;
}
fn main() {
let x = [(); <[(); 4] as Trait>::N];
}
```
Figuring out which specific cases are not currently accepted by stable is quite hairy.
Upon discussion with @BoxyUwU, she suggested that *all* consts, including free consts, should require `#[type_const]` to be able to be referred to. This is what this PR does.
---
~~The change to `tests/ui/const-generics/generic_const_exprs/non-local-const.rs` is unfortunate, reverting the fix in rust-lang#143106 no longer fails the test. Any suggestions to test it more appropriately would be most welcome!~~
edit: never mind, figured out how compiletests work :) - verified that the new test setup correctly ICEs when that PR's fix is reverted.
r? @BoxyUwU
rust-timer
added a commit
that referenced
this pull request
Feb 6, 2026
Rollup merge of #152129 - khyperia:require-type_const-on-free-consts, r=BoxyUwU MGCA: require #[type_const] on free consts too When investigating another issue, I discovered that following ICEs (the `const_of_item` query doesn't support non-type_const-marked constants and does a `span_delayed_bug`): ```rust #![feature(min_generic_const_args)] #![allow(incomplete_features)] const N: usize = 4; fn main() { let x = [(); N]; } ``` My initial thought of "only require `#[type_const]` on places that stable doesn't currently accept" ran into the issue of this compiling on stable today: ```rust trait Trait { const N: usize; } impl<const PARAM: usize> Trait for [(); PARAM] { const N: usize = PARAM; } fn main() { let x = [(); <[(); 4] as Trait>::N]; } ``` Figuring out which specific cases are not currently accepted by stable is quite hairy. Upon discussion with @BoxyUwU, she suggested that *all* consts, including free consts, should require `#[type_const]` to be able to be referred to. This is what this PR does. --- ~~The change to `tests/ui/const-generics/generic_const_exprs/non-local-const.rs` is unfortunate, reverting the fix in #143106 no longer fails the test. Any suggestions to test it more appropriately would be most welcome!~~ edit: never mind, figured out how compiletests work :) - verified that the new test setup correctly ICEs when that PR's fix is reverted. r? @BoxyUwU
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #133808
I have absolutely no idea what I'm doing here, but I followed @BoxyUwU 's instructions, and turns out this small change fixes #133808, and doesn't seem to break anything else.
(This code path is only reachable when the GCE feature gate is enabled, so even if it does break in a way that is not caught by current test coverage, I guess it's not as bad as breaking stable or non-incomplete features?)
Anyways, r? @BoxyUwU , if you don't mind.