Tracking issue for RFC 2341, Allow locals and destructuring in const fn

[Centril]

This is a tracking issue for the RFC "Allow locals and destructuring in const fn" (rust-lang/rfcs#2341).

Steps:

• Implement the RFC (cc @oli-obk - just remove the few checks)
• Adjust documentation (Document const_let reference#506)
• Stabilize (proposal: Stabilize let bindings and destructuring in constants and const fn #57175 (comment))
• Fix short-circuiting operators Wrong result after short circuit in const_let #53515 (no longer compiles on nightly -- Wrong result after short circuit in const_let #53515 (comment))

Unresolved questions:

None.

[eddyb]

just remove the few checks

It's a bit trickier, because rustc_mir::transform::qualify_consts needs to track local variables just like it does only temporaries right now, but it shouldn't

Also, was let in other const contexts in the RFC, i.e. const X: i32 = { let x = 2 + 3; x * x};?

[Centril]

@eddyb Feel free to edit the issue description =)

Also, was let in other const contexts in the RFC, i.e. const X: i32 = { let x = 2 + 3; x * x}; ?

Yes, because (quoting the summary):

Allow let bindings in the body of constants and const fns. Additionally enable destructuring in let bindings and const fn arguments.

[bstrie]

A question about the "Drawbacks" section from the original RFC:

You can create mutable locals in constants and then actually modify them. This has no real impact on the constness, as the mutation happens entirely at compile time and results in an immutable value.

Can you elaborate on this? Is this just referring to something like const foo: i32 = { let mut x = 0; x += 1; x };? That's my straightforward reading of the text, but it also seems completely expected so I'm not sure whether there's a more pernicious drawback I ought to be seeing.

[oli-obk]

Not a drawback really, but a note that this is new behaviour, because before you could never modify the same memory twice, only emulate the same program behaviour via const fn.

[oli-obk]

This works now on nightly (behind a feature gate). Please play around with this feature liberally and report any findings! Any help in documenting and pushing it over the stabilization line is appreciated.

[nexplor]

There seems to be a bug in the current implementation. This should work, right? http://play.rust-lang.org/?gist=5009873918b2b45bfa8015d4f21bb355&version=nightly&mode=debug&edition=2015

[oli-obk]

Imo it would be fine if added behind its own feature gate. So if you're looking for something easy to do:

1. add a new feature gate (just search for const_let and copy all the defining parts)
2. wrap https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L276 in a feature gate check (so if the feature gate is active, then that line needs to be not called)
3. Add regression tests