Evaluation with inconsistent `where`-clauses

[lcnr]

What is this

This is a design document for const generics. Any discussions about its content should be on zulip. The conclusions of these discussions should then be edited back into this issue. Please do not post any comments directly in this issue.

Content

When checking where-bounds containing anonymous constants, we evaluate these constants without first checking whether the required where-bounds hold for constant.
play

trait Foo {
    type Assoc;
    const ASSOC: <Self as Foo>::Assoc;
}

impl Foo for i32 {
    type Assoc = i64;
    const ASSOC: i64 = 3;
}

const fn bar<T>(x: T) -> usize {
    std::mem::forget(x);
    3
}

fn foo<T>() where
    T: Foo<Assoc = T>,
    [u8; bar::<T>(<T as Foo>::ASSOC)]: Sized,
{}

fn main() {
    foo::<i32>();
}

When using foo we have to first prove that it is well formed. This is done by proving its where-clauses. Checking that this is the case requires us to evaluate bar::<T>(<T as Foo>::ASSOC). During const evaluation we assume that everything we evaluate is well formed. As we evaluate the anonymous constant while checking that the where-clauses of foo hold, this is actually not the case.

Evaluating constants containing inference variables

In the past we ended up with quite a few ICE after evaluating constants which contain inference variables. The underlying reason behind these ICE is exactly this issue, where instead of having incorrect substs because we're currently checking the where-clauses containing the constant, we only have insufficient information about the inference variables, preventing us from proving the necessary predicates.

Stop requiring constants to be well formed during CTFE

We rely on constants being well-formed during mir building in quite a few - potentially quite subtle - ways.

To prevent CTFE from causing errors or ICE when run with inconsistent bounds we would have to fix all of these issues, which already seems difficult. Even worse, by allow more incoherent states in the mir, we may also fail to detect compiler bugs.

Check bounds of anonymous constants separately before evaluation

This would generally work but breaks on #36 for constants in where-clauses, as we would have to prove that constants are evaluatable while trying to evaluate them.

Typecheck constants with substs applied before evaluation

Using the param_env of the caller and the generic arguments supplied by the caller, typecheck constants before evaluation after applying the generic arguments.

While this should fix this issue, it probably causes a fairly large performance impact and generally just doesn't feel great.