Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rollup merge of rust-lang#54346 - eddyb:constant-horror, r=nikomatsakis
rustc: future-proof error reporting for polymorphic constants in types. Currently, we have 3 categories of positions where a constant can be used (`const` and associated `const` can be considered "aliases" for an expression): * runtime - if the function is polymorphic, we could even just warn and emit a panic * `static` - always monomorphic, so we can error at definition site * type-system - **must** *enforce* evaluation success where it was written That last one is the tricky one, because we can't easily turn *the presence* a type with an erroring const into a runtime panic, and we'd have to do post-monomorphization errors (which we'd rather avoid). <hr/> The solution we came up with, as part of the plans for const generics, is to require successful evaluation wherever a constant shows up in a type (currently in array lengths, and values for const parameters in the future), *through* the WF system, which means that in certain situations (e.g. function signatures) we can assume evaluation *will* succeed, and require it of users (e.g. callers) instead (we've been doing this for lifetime bounds, for a long time now, and it's pretty ergonomic). So once we do sth about rust-lang#43408, this example *should* work, by propagating the responsability, to callers of `foo::<X>`, of proving `std::mem::size_of::<X>()` succeeds (and those callers can do the same). ```rust pub fn foo<T>(_: [u8; std::mem::size_of::<T>()]) {} ``` But this one *shouldn't*, as there is nothing in the signature/bounds to indicate it: ```rust pub fn bar<T>() { let _: [u8; std::mem::size_of::<T>()]; } ``` <hr/> I've come across some bit of code in the compiler that ignores const-evaluation errors *even when* they come from a constant in a type, and I've added an ICE *only when* there are no other reported errors (e.g. it's fine to ignore evaluation errors if the constant doesn't even type-check). r? @nikomatsakis cc @oli-obk @RalfJung @Centril
- Loading branch information