-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[ICE]: Encountered anon const with inference variable args but no error reported #133199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
are you using any unstable features, do you have a link to the ICEing code or something that would be useful in debugging this? |
@BoxyUwU I am using this #![feature(generic_const_exprs)] |
Looks like #133243 has a reproducer but not minimal. (That report didn't incl. dep version info, asking) |
MCVE from #133243 (ICEs on master checkout as of bfe809d): // tests/ui/generic_const_exprs/meow.rs
//@ aux-build: fixed_bit_set.rs
extern crate fixed_bit_set;
use fixed_bit_set::FixedBitSet;
fn main() {
FixedBitSet::<7>::new();
//~^ ERROR
} // tests/ui/generic_const_exprs/auxiliary/fixed_bit_set.rs
#![allow(incomplete_features)]
#![feature(generic_const_exprs)]
pub struct FixedBitSet<const N: usize>;
impl<const N: usize> FixedBitSet<N>
where
[u8; N.div_ceil(8)]: Sized,
{
pub fn new() -> Self {
todo!()
}
} |
Note that in the MCVE, the cross-crate seems to be a necessary condition. Inlining the struct and |
FWIW: The jolt quickstart example produces this error on an M1
produces:
Nightly version:
|
I also encountered this bug. I did not manage to reduce the bug to a simple code example but I can share my repo: The bug reproduces when running
Error output
rustc-ice-2024-11-30T07_58_44-194488.txt Backtrace
|
This comment has been minimized.
This comment has been minimized.
Fyi, I use nightly 2024-11-01 where this issue is not yet present. I have not pinned down exactly when the issue appears but 2024-12-01 does not work, so sometimes in between... |
In my case, which was a parent crate crashing because of its dependency to a child crate who used const generics, adding |
Yeah, I'm only aware of this ICE occuring in cross crate scenarios. If adding |
Adding |
@BoxyUwU In a similar issue (I can't be sure if it's a duplicate) REMOVING #![feature(generic_const_exprs)] from the consumer crate (in my instance it's in the inline test) prevents the ICE (and then rustc shows an actual compile error). Please see #134044 (comment). Even though it was me who somehow narrowed it somewhat down (with the previous help of @cyrgani), I don't remember too much - it was 2 weeks ago... If it doesn't make sense, let me know and I'll dive again. Note that in the code reported earlier in that issue (#134044), that is: before the above linked comment, |
Some of them were missing this feature annotation but used to compile and pass for some inexplicable reason. Now this missing feature gate causes an ICE (rust-lang/rust#133199). This adds the feature gates in all the doctests, but does not yet address the fact that this ICE also occurs in calling crates that don't have `#![feature(generic_const_exprs)]` set. Maybe a workaround could be to check for this feature explicitly and throw a helpful error message in diman.
Some of them were missing this feature annotation but used to compile and pass for some inexplicable reason. Now this missing feature gate causes an ICE (rust-lang/rust#133199). This adds the feature gates in all the doctests, but does not yet address the fact that this ICE also occurs in calling crates that don't have `#![feature(generic_const_exprs)]` set. Maybe a workaround could be to check for this feature explicitly and throw a helpful error message in diman.
Some of them were missing this feature annotation but used to compile and pass for some inexplicable reason. Now this missing feature gate causes an ICE (rust-lang/rust#133199). This adds the feature gates in all the doctests, but does not yet address the fact that this ICE also occurs in calling crates that don't have `#![feature(generic_const_exprs)]` set. Maybe a workaround could be to check for this feature explicitly and throw a helpful error message in diman.
Some of them were missing this feature annotation but used to compile and pass for some inexplicable reason. Now this missing feature gate causes an ICE (rust-lang/rust#133199). This adds the feature gates in all the doctests, but does not yet address the fact that this ICE also occurs in calling crates that don't have `#![feature(generic_const_exprs)]` set. Maybe a workaround could be to check for this feature explicitly and throw a helpful error message in diman.
have a shorter mrp. two crates: bar #![allow(incomplete_features)]
#![feature(generic_const_exprs)]
pub fn pop<const N: usize>(_: [(); N]) -> [(); N - 1] {
panic!()
} main pub fn main() {
bar::pop([()]);
} thanks to @theemathas and @pitust for minimizing Shortest possible mrp, i think. |
The "fix" is to add #![feature(generic_const_exprs)] to the top of every crate that depends on your crate, and to the top of every doctest. |
…mpiler-errors Defer evaluating type system constants when they use infers or params Split out of rust-lang#137972, the parts necessary for associated const equality and min generic const args to make progress and have correct semantics around when CTFE is invoked. According to a [previous perf run](https://perf.rust-lang.org/compare.html?start=93257e2d20809d82d1bc0fcc1942480d1a66d7cd&end=01b4cbf0f47c3f782330db88fa5ba199bba1f8a2&stat=instructions:u) of adding the new `const_arg_kind` query we should expect minor regressions here. I think this is acceptable as we should be able to remove this query relatively soon once mgca is more complete as we'll then be able to implement GCE in terms of mgca and rip out `GCEConst` at which point it's trivial to determine what kind of anon const we're dealing with (either it has generics and is a repeat expr hack, or it doesnt and is a normal anon const). This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters. Fixes rust-lang#133066 Fixes rust-lang#133199 Fixes rust-lang#136894 Fixes rust-lang#137813 r? compiler-errors
Code
Affected release channels
Rust Version
Current error output
Backtrace
Anything else?
No response
The text was updated successfully, but these errors were encountered: