Constant gets evaluated despite unsatisfied where clauses

[RalfJung]

This is the rustc side of rust-lang/project-const-generics#37.

[RalfJung]

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 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.

Cc @rust-lang/project-const-generics

[RalfJung]

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!().

[lcnr]

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_exprs issues.

[RalfJung]

This is rust-lang/project-const-generics#37 probably

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]

yes, I think switching this back to a span_bug! is good