Const's ty field, what is it good for

Random information

The ty field on const stores what kind the const parameter is (note: this is intended to be the type theory meaning of a generic kind, not to be confused with ConstKind). When using a Const argument we have to ensure that the provided arg is of the same type/kind as the actual param:

fn foo<const N: u8>() {}

fn bar() {    
    foo::<10_u16>();
}
//~^ should error because providing a `u16` value to a `u8` const param
//    is not legal

The bar item does not actually perform any checks that the correct kinds of const parameters are provided as arguments.

Every const generic argument is desugared to an anonymous const item which is typeck'd separately from its parent item. When typeck'ing the const item the return type is set to the type of the const param it is an argument for.

An exception to this is arguments that are being inferred, either via the generic_arg_infer feature or when generics in paths have been elided. These do not have anon consts.

We currently do not relate the ty field when relating consts, instead we just ICE if the two ty's compared via PartialEq are not the same.

If we were to support directly using const items (i.e. assoc consts) as const arguments for a min_generic_const_exprs(mgce) (i.e. foo::<<T as Trait<_>>::ASSOC>()) There would no longer be an anon const getting typeck'd and we would need to actually check that the types of const arguments are correct.

If we were to support const generics that have types that depend on other generics it would be valuable to allow "forward declared" types of const params, i.e. struct Foo<const N: T, T>, as otherwise you could not have a non-defaulted const parameter of a type that has default i.e. struct Foo<const N: T, T = u32>. This would mean we are no longer able to construct the expected ty of the const arg during ast lowering for the substs, it would only be available once they have all been built.

Allowing this would make the current planned query feeding solution for typechecking anonymous constants inadequate as we would be able to end up with infer vars in the expected type and we are unable to have infer vars in query inputs/outputs:

fn foo<T, const N: T>() -> T { N }

fn main() {
    let mut a = foo::<_, { 1 }>();
    //                   ^^^^^ expected type would be `_`
    a = 1_u8;
}

If we're allowing const N: T, T, as previously mentioned, we would not even be able to construct the expected type to feed even if it did not contain infer vars, i.e. foo::<{ 1 }, u8>().

Additionally it would be nice if the following were to compile:

fn foo<const N: T, T = bool>() {}

fn main() {
    foo::<{ 1_u8 }, _>();
}

This would require inferring the type infer var to u8 by typechecking the anon const.

Currently super_relate_consts has an assertion that both Const's have the same ty. This is at first was implemented via just == but this is inadequate.

With adt_const_params we can have const/type aliases in the ty which makes == spurriously return false leading to ICEs. type alises are eagerly normalized at the moment so only const aliases which use lazy norm cause problems. To fix this we currently call normalize_erasing_regions in super_relate_consts before ==.

Under mgce or T, const N: T we wil start getting infer vars in the ty at which point this will also start spurriously ICEing because of things like ?0 == ?1 not being true even though they might end up getting constrained by the end of the type relation.

This assertion has caught many bugs so keeping it in some form will be valuable so just flat out removing it is not desirable.

Changes to make

A ConstParamHasType obligation that requires a Const have a type equal to some Ty would potentially solve two issues that mgce would have:

• Would actually check that provided args are of the correct type
• Is checked after substs are built allowing forward declared const parameter types

And as outlined in pcg-44:

• Would allow for less error prone trait/impl checks (a win for even min const generics)

Implemented in #107965

Note: dont actually know if this is possible or not

Start type checking anon consts as part of the parent body and lower anon const const args to infer vars. When the anon const has been fully type checked use query feeding to create the defid for the anon const and relate a ConstKind::Unevaluated with the previously created infer var. This should be "necessary" even without supporting generic anon consts i.e. N + 1. Just supporting fn foo<const N: T, T> and foo::<{ 1_u8 }, _>(); will likely need this.

• This should allow for the desired type inference quality where type checking the anon const can infer the return type and type checking the function can infer the anon const's return type.
• Sidesteps the problem of not having the expected type available during astconv of substs as we only actually create the anon const once the return type has been inferred
• Don't have to deal with infer vars in the type_of returned value as we only create the anon const after the return type has been inferred

Not yet implemented

Change the assertion in super_relate_consts from a_ty == b_ty to instead actually relate the two tys inside of a probe and ICE if it returns an error.

• It's important to do it inside of a probe as this assertion should not help code to compile.
• The assertion likely will not catch every mistake as it will succeed for ?0 eq ?1 even if we never actually relate the two infer vars outside of the probe

Implemented in #107940