rustc: future-proof error reporting for polymorphic constants in types. #54346
Conversation
rust-highfive
added
the
S-waiting-on-review
|
@bors try (for cargo check, let's see if there's anything we haven't thought of) |
|
⌛ Trying commit 046482e with merge fcacde07b66fe513e52c41b73aef91bcc121905b... |
|
☀️ Test successful - status-travis |
|
@craterbot run start=master#ff6422d7a392acfc8af28994d65af2bbaecea4f6 end=try#fcacde07b66fe513e52c41b73aef91bcc121905b mode=check-only |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
r=me modulo crater |
|
This PR is completely overwritten by #53821. |
|
@RalfJung Yeah, if that lands first (assuming the crater run here succeeds), I'll just close this one. |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
Both regressions say "c++: internal compiler error: Killed (program cc1plus)", looks spurious to me. |
|
📌 Commit 046482e has been approved by |
bors
added
S-waiting-on-bors
|
Hang on - would it be possible to automatically search all the logs for the ICE message introduced here? ( |
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
Rollup of 15 pull requests Successful merges: - #52813 (Duration div mul extras) - #53470 (Warn about metadata loader errors) - #54233 (Remove LLVM 3.9 workaround.) - #54257 (Switch wasm math symbols to their original names) - #54258 (Enable fatal warnings for the wasm32 linker) - #54266 (Update LLVM to fix "bool" arguments on PPC32) - #54290 (Switch linker for aarch64-pc-windows-msvc from LLD to MSVC) - #54292 (Suggest array indexing when tuple indexing on an array) - #54295 (A few cleanups and minor improvements to rustc/traits) - #54298 (miri: correctly compute expected alignment for field) - #54333 (Update The Book to latest) - #54337 (Remove unneeded clone() from tests in librustdoc) - #54346 (rustc: future-proof error reporting for polymorphic constants in types.) - #54362 (Pass --batch to gdb) - #54367 (Add regression test for thread local static mut borrows)
Currently, we have 3 categories of positions where a constant can be used (
constand associatedconstcan be considered "aliases" for an expression):static- always monomorphic, so we can error at definition siteThat 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).
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 #43408, this example should work, by propagating the responsability, to callers of
foo::<X>, of provingstd::mem::size_of::<X>()succeeds (and those callers can do the same).But this one shouldn't, as there is nothing in the signature/bounds to indicate it:
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