Stream: t-compiler/const-eval

Topic: Initial implementation of `if` and `match` in constants


ecstatic-morse (Nov 18 2019 at 05:58, on Zulip):

#66507 is now up with an initial implementation of RFC 2342 (allow if and match in constants #49146). This is my first PR that adds a new feature to rust, so hopefully I didn't do anything too weird. Let me know if I missed anything obvious, or if you have ideas for tests (coverage is pretty sparse at the moment).

centril (Nov 18 2019 at 07:58, on Zulip):

Taking a look :slight_smile:

oli (Nov 18 2019 at 08:45, on Zulip):

omfgz :tears: It's been three years (for me) and we are finally getting there

ecstatic-morse (Nov 18 2019 at 19:31, on Zulip):

I think we should try to come up with a comprehensive list of tests that we want. It's hard for me to keep track of ad-hoc suggestions in comments. If we weren't concerned about readability, we would want the cartesian product of every category below.

I personally feel comfortable not testing every const-context, but instead having just one test that does this (currently this is control-flow/loop.rs). Also I think we don't need to do both const/runtime asserts everywhere.

const contexts:
- const
- static and static mut
- const fn
- array initializer
- const generic param

branching constructs
- if
- if let
- match
- && and ||
- single-arm match

ways to check results
- const assert
- runtime assert

qualifs
- NeedsDrop
- HasMutInterior

oli (Nov 19 2019 at 10:20, on Zulip):

yea one const context totally suffices. Although I think we should just keep forbidding it in static mut

oli (Nov 19 2019 at 10:20, on Zulip):

I don't want to think about the extra features available in static mut that may make this messy

oli (Nov 19 2019 at 10:22, on Zulip):

A few const fn tests would be good, too, because they are a bit different from constants due to having arguments

oli (Nov 19 2019 at 10:24, on Zulip):

if there's a few if tests, it seems sufficient to just keep match everywhere

oli (Nov 19 2019 at 10:27, on Zulip):

&& and || are lowered in a way where I don't see how it would be beneficial to test them over just testing nested matches

oli (Nov 19 2019 at 10:27, on Zulip):

same with if let

oli (Nov 19 2019 at 10:28, on Zulip):

so basically... test everything somewhere, but do the qualif and assert tests only with match

centril (Nov 19 2019 at 12:26, on Zulip):

yea one const context totally suffices.

That depends entirely on how many differences there are between the contexts

centril (Nov 19 2019 at 12:26, on Zulip):

I think we can generally collapse "const, array init, enum discr" to just "const"

centril (Nov 19 2019 at 12:27, on Zulip):

but having some tests for all context would also be good

centril (Nov 19 2019 at 12:28, on Zulip):

if there's a few if tests, it seems sufficient to just keep match everywhere

This sort of assumes that the desugaring will always use match, but I don't think it will in the future

centril (Nov 19 2019 at 12:28, on Zulip):

To throw in more categories, we'll also need tests for ref mut

centril (Nov 19 2019 at 12:30, on Zulip):

I think we should err on the side of high test coverage here as the analysis is complicated and the interactions are many

centril (Nov 19 2019 at 12:30, on Zulip):

(but we can also add tests over time...)

RalfJ (Nov 19 2019 at 15:47, on Zulip):

I don't want to think about the extra features available in static mut that may make this messy

IMO it is more messy to special-case static mut

ecstatic-morse (Nov 19 2019 at 18:53, on Zulip):

if there's a few if tests, it seems sufficient to just keep match everywhere

This sort of assumes that the desugaring will always use match, but I don't think it will in the future

The MIR-level checks that use dataflow analysis for NeedsDrop and HasInteriorMut won't really be affected by desugaring. It all ends up as a SwitchInt eventually. That's why I avoided duplicating tests across multiple high-level constructs.

ecstatic-morse (Nov 19 2019 at 18:54, on Zulip):

The HIR checks on the other hand should be tested across all high-level constructs.

ecstatic-morse (Nov 19 2019 at 18:56, on Zulip):

Which currently happens in constrol-flow/loops.rs, but I should replicate this test for if/match as well.

ecstatic-morse (Nov 19 2019 at 19:06, on Zulip):

@oli static mut allows you to create &mut slices, which is kind of scary, but Deref projections of them are forbidden, meaning you can't really mutate them.

ecstatic-morse (Nov 19 2019 at 21:15, on Zulip):

I think I lean towards allowing if/match in static mut for now, since it makes it easier for the community to try and break it. We should add this to #49146 as a question to resolve before stabilization though.

ecstatic-morse (Nov 19 2019 at 21:16, on Zulip):

@oli I'd also like to write a rust internals post before this gets released on nightly explaining some of the weirdness around Drop types and interior mutability in consts.

oli (Nov 20 2019 at 11:30, on Zulip):

The HIR checks on the other hand should be tested across all high-level constructs.

right, but these don't need the combinatorial explosion for everything, just once per construct instead of once per test per construct per qualif bit

oli (Nov 20 2019 at 11:31, on Zulip):

oli static mut allows you to create &mut slices, which is kind of scary, but Deref projections of them are forbidden, meaning you can't really mutate them.

well... that's something we'll want to allow at some point, so we'll have to keep it in mind

oli (Nov 20 2019 at 11:36, on Zulip):

We can certainly delay merging the PR until there's a blogpost explaining it

oli (Nov 20 2019 at 11:49, on Zulip):

side note when reading https://github.com/rust-lang/blog.rust-lang.org/pull/461/files : while we should feature gate loops and conditions separately, we should probably stabilize together so we don't nudge ppl into writing loops via recursion

centril (Nov 20 2019 at 15:17, on Zulip):

agree wrt. stabilizing together; had the same thought

centril (Nov 20 2019 at 15:17, on Zulip):

I also think we should go nuts with using rustc_const_unstable everywhere as much as we can to test the implementation and see how far it takes us

centril (Nov 20 2019 at 15:18, on Zulip):

then we can FCP the actual stabilizations

centril (Nov 20 2019 at 15:18, on Zulip):

(well we need to stabilize the language features first)

centril (Nov 20 2019 at 15:18, on Zulip):

We'll also need to test stuff like ref mut btw

Last update: Dec 12 2019 at 00:50UTC