about summary refs log tree commit diff
path: root/src/libsyntax/parse/parser.rs
diff options
context:
space:
mode:
authorkennytm <kennytm@gmail.com>2018-09-20 21:36:34 +0800
committerkennytm <kennytm@gmail.com>2018-09-20 23:28:03 +0800
commitf2aabb713820c3f4077fec4d0488d48ba493f965 (patch)
treeccb174c1f997af5046002edcd817d26f58376865 /src/libsyntax/parse/parser.rs
parentf5b8c7fa1606cbd8bf25f448eed8c7998e30145d (diff)
parent046482e95e1b01a7f2ef01ffb7592db5045ad508 (diff)
downloadrust-f2aabb713820c3f4077fec4d0488d48ba493f965.tar.gz
rust-f2aabb713820c3f4077fec4d0488d48ba493f965.zip
Rollup merge of #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 #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
Diffstat (limited to 'src/libsyntax/parse/parser.rs')
0 files changed, 0 insertions, 0 deletions