feature(associated_const_equality) allows const arguments to generic const parameters
#108271
Assignees
Labels
A-const-generics
Area: const generics (parameters and arguments)
C-bug
Category: This is a bug.
F-associated_const_equality
`#![feature(associated_const_equality)]`
glacier
ICE tracked in rust-lang/glacier.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
P-medium
Medium priority
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
BoxyUwU
added
I-ICE
BoxyUwU
added
the
F-associated_const_equality
|
The first code snippet in this issue did not used to ICE on stable: pub trait TraitWAssocConst<T> {
const A: T;
}
fn main<T, B: TraitWAssocConst<T, A = { 1 }>>() {}
cc @oli-obk @JulianKnodt since you were both involved with this feature's implementation @rustbot label +regression-from-stable-to-stable |
rustbot
added
regression-from-stable-to-stable
BoxyUwU
added
the
A-const-generics
|
As mentioned in #108165 the new error message originates in 9556b56
The ICE is the stable-to-stable regression here and if my bisection is correct (I'm not 100% sure) it dates back to nightly nightly-2022-02-03: |
apiraino
removed
the
I-prioritize
|
Hey, I just stumbled upon this issue while testing the interaction of generic (associated) consts (that I'm in the process of implementing as you may remember) and associated const equality. @BoxyUwU (edit:) or rather @oli-obk, since I'm not that familiar yet with the implementation specifics of associated const equality (sth sth assoc const projections), would you say this ICE to be easy-ish to fix? Ideally ICE->pass instead of ICE->errors? I hope this is less difficult to implement architecturally speaking than straight up generic const generics which look kinda related ^^'. Would anyone like to mentor me on this at some point unless somebody already planned to work on this of course? :) Edit: Ah, just noticed #108172 (comment). So it's indeed generic const generics 😢 |
|
I wouldn't try to fix this by making it compile rn, it's pretty much blocked on implementing a |
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Mar 18, 2024
…y-generic-tys, r=compiler-errors Reject overly generic assoc const binding types Split off from rust-lang#119385 to make rust-lang#119385 easier to review. --- In the *instantiated* type of assoc const bindings 1. reject **early-bound generic params** * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)). * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*. * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error. 2. reject **escaping late-bound generic params** * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics* --- Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360. Fixes rust-lang#108271.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 18, 2024
…y-generic-tys, r=compiler-errors Reject overly generic assoc const binding types Split off from rust-lang#119385 to make rust-lang#119385 easier to review. --- In the *instantiated* type of assoc const bindings 1. reject **early-bound generic params** * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)). * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*. * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error. 2. reject **escaping late-bound generic params** * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics* --- Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360. Fixes rust-lang#108271.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 18, 2024
Rollup merge of rust-lang#121258 - fmease:assoc-const-eq-reject-overly-generic-tys, r=compiler-errors Reject overly generic assoc const binding types Split off from rust-lang#119385 to make rust-lang#119385 easier to review. --- In the *instantiated* type of assoc const bindings 1. reject **early-bound generic params** * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)). * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*. * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error. 2. reject **escaping late-bound generic params** * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics* --- Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360. Fixes rust-lang#108271.
This was referenced Mar 19, 2024
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Mar 19, 2024
…-tys, r=compiler-errors Reject overly generic assoc const binding types Split off from #119385 to make #119385 easier to review. --- In the *instantiated* type of assoc const bindings 1. reject **early-bound generic params** * Provide a rich error message instead of ICE'ing ([#108271](rust-lang/rust#108271)). * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*. * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error. 2. reject **escaping late-bound generic params** * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics* --- Together with #118668 & #119385, this supersedes #118360. Fixes #108271.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code
Meta
Both code snippets ICE on the following version as we added an assert that we do not support arguments to generic const parameters
rustc --version --verbose:The first code snippet ICEs before we added that assertion
rustc --version --verbose:Error output
for the first code snippet on stable:
Backtrace on new rustc
Backtrace on old rustc
The text was updated successfully, but these errors were encountered: