Constant gets evaluated despite unsatisfied where clauses #97477
Assignees
Labels
A-const-eval
Area: Constant evaluation, covers all const contexts (static, const fn, ...)
A-const-generics
Area: const generics (parameters and arguments)
F-generic_const_exprs
`#![feature(generic_const_exprs)]`
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
requires-incomplete-features
This issue requires the use of incomplete features.
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-const-eval
Working group: Const evaluation
Comments
RalfJung
added
the
A-const-eval
RalfJung
added
A-const-generics
|
An example of code that runs into this comes from this issue: // check-fail
// This test used to cause an ICE in rustc_mir::interpret::step::eval_rvalue_into_place
#![allow(incomplete_features)]
#![feature(generic_const_exprs)]
use std::fmt::Debug;
use std::marker::PhantomData;
use std::mem::size_of;
struct Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
_phantom: PhantomData<T>,
buf: [u8; size_of::<T>() + 1],
}
impl<T> Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
pub fn new(val: T) -> Inline<T> {
todo!()
}
}
fn main() {
let dst = Inline::<dyn Debug>::new(0); //~ ERROR
//~^ ERROR
}So, looks like a problem with const generics? Something is trying to evaluate Given that this code is clearly wrong, wouldn't it be better to ICE instead of having this Cc @rust-lang/project-const-generics |
|
In fact the really strange part is that the const-eval error is the only error being emitted. It looks like there's literally nothing else preventing the unsized type to flow into a generic context that assumes EDIT: Ah no, that's wrong. The sized error shows up. But it shows up later. By the time const-eval runs, no error has been emitted yet. Or is that just some error buffering thing? But that can't quite be, "no errors encountered even though |
|
This is rust-lang/project-const-generics#37 probably 🤔 we have to evaluate the constant to check where-clauses but the constant is only well-formed if the where-clauses hold. Evaluating constants when proving where-clauses causes a bunch of issues. This is one of the big |
Ah yes that sounds similar to what we are seeing. So... any objections to turning this back into a |
|
yes, I think switching this back to a |
RalfJung
changed the title
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Aug 8, 2023
…r=lcnr interpret: remove incomplete protection against invalid where clauses Cc rust-lang#97477, rust-lang/project-const-generics#37 r? `@lcnr`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Aug 8, 2023
…r=lcnr interpret: remove incomplete protection against invalid where clauses Cc rust-lang#97477, rust-lang/project-const-generics#37 r? ``@lcnr``
|
Stacktrace of #97477 (comment) for findability: |
matthiaskrgr
added
the
I-ICE
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 17, 2023
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving rust-lang#97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 18, 2023
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving rust-lang#97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 18, 2023
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving rust-lang#97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 23, 2023
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving rust-lang#97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Oct 24, 2023
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving rust-lang/rust#97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this issue
Nov 2, 2023
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving rust-lang/rust#97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
workingjubilee
added
the
requires-incomplete-features
jackh726
added
the
S-bug-has-test
jieyouxu
added
T-compiler
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the rustc side of rust-lang/project-const-generics#37.
The text was updated successfully, but these errors were encountered: