You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Constant gets evaluated despite unsatisfied where clauses #97477
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;structInline<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]:,{pubfnnew(val:T) -> Inline<T>{todo!()}}fnmain(){let dst = Inline::<dynDebug>::new(0);//~ ERROR//~^ ERROR}
So, looks like a problem with const generics? Something is trying to evaluate size_of::<T>() + 1 despite T: ?Sized. That makes me wonder which other kind of invalid MIR const generics might execute?
Given that this code is clearly wrong, wouldn't it be better to ICE instead of having this SizeOfUnsizedType error variant that should not exist? It is marked as an incomplete feature after all, so ICEs are expected. And the current "fix" is papering over the ICE, not fixing the root cause.
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 T: Sized. How can that be?
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 delay_span_bug issued" shows up when I make it do delay_span_bug and then bug!().
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 generic_const_exprs issues.
So... any objections to turning this back into a span_bug!? The underlying issue is far from fixed by this one extra check (as your issue shows), and I think if we want to get the interpreter into a state where it can run even in the presence of violated where clauses, we need to do some solid planning. I don't even know how many invariants there are that this can break, I worry that it is a lot and we'd get a never-ending stream of ICEs until we identify most of them (and more ICEs each time the interpreter is changed and relies on a new invariant that doesn't have a matching test yet).
changed the title [-]Constant gets evaluated even when it contains SizeOf on unsized type[/-][+]Constant gets evaluated despite unsatisfied where clauses[/+]on Aug 8, 2023
Activity
RalfJung commentedon Aug 6, 2023
An example of code that runs into this comes from this issue:
So, looks like a problem with const generics? Something is trying to evaluate
size_of::<T>() + 1despiteT: ?Sized. That makes me wonder which other kind of invalid MIR const generics might execute?Given that this code is clearly wrong, wouldn't it be better to ICE instead of having this
SizeOfUnsizedTypeerror variant that should not exist? It is marked as an incomplete feature after all, so ICEs are expected. And the current "fix" is papering over the ICE, not fixing the root cause.Cc @rust-lang/project-const-generics
RalfJung commentedon Aug 6, 2023
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
T: Sized. How can that be?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
delay_span_bugissued" shows up when I make it dodelay_span_bugand thenbug!().lcnr commentedon Aug 7, 2023
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
generic_const_exprsissues.RalfJung commentedon Aug 7, 2023
Ah yes that sounds similar to what we are seeing.
So... any objections to turning this back into a
span_bug!? The underlying issue is far from fixed by this one extra check (as your issue shows), and I think if we want to get the interpreter into a state where it can run even in the presence of violated where clauses, we need to do some solid planning. I don't even know how many invariants there are that this can break, I worry that it is a lot and we'd get a never-ending stream of ICEs until we identify most of them (and more ICEs each time the interpreter is changed and relies on a new invariant that doesn't have a matching test yet).lcnr commentedon Aug 7, 2023
yes, I think switching this back to a
span_bug!is good[-]Constant gets evaluated even when it contains SizeOf on unsized type[/-][+]Constant gets evaluated despite unsatisfied where clauses[/+]Rollup merge of rust-lang#114615 - RalfJung:interpret-invalid-where, …
Rollup merge of rust-lang#114615 - RalfJung:interpret-invalid-where, …
matthiaskrgr commentedon Aug 9, 2023
Stacktrace of #97477 (comment) for findability:
Auto merge of rust-lang#116849 - oli-obk:error_shenanigans, r=<try>
Auto merge of rust-lang#116849 - oli-obk:error_shenanigans, r=<try>
Auto merge of rust-lang#116849 - oli-obk:error_shenanigans, r=<try>
Auto merge of rust-lang#116849 - oli-obk:error_shenanigans, r=cjgillot
Auto merge of #116849 - oli-obk:error_shenanigans, r=cjgillot
Auto merge of #116849 - oli-obk:error_shenanigans, r=cjgillot