const-evaluation

[nikomatsakis]

Summary

Const-evaluation, language team impact

Links

• Repository rust-lang/const-eval
• Zulip stream t-compiler/const-eval

[nikomatsakis]

• Oli working on skill-tree to help plan next steps for const-eval
  • loop and while (not for) is the next candidate for stabilization.
    • Main blocker was questions around qualification à la if and match.
    • Having if and match w/o loop and while will push people to use recursion for loops in a const context (I believe this happened with C++’s constexpr).
    • Having no for loops, which would require const trdait methods, is painful though.
• Inline const { … } expressions (and patterns)
  • Inline const expressions and patterns rfcs#2920
  • Do we allow code inside a const { … } to depend on generic parameters?
  • Does unsafe { const { … } } allow unsafe operations inside the inline const?
    • See unsafe blocks do not apply to array length expressions they contain rust#72359 for background
  • Do we allow const { … } in fallible patterns?

[nikomatsakis]

• RFC 2342, "Allow if and match in constants"
  • Stabilization PR
  • Oli wants to tie to stabilization to loops (see below).

[nikomatsakis]

• RFC 2344, "Allow loop in constant evaluation
  • Stabilization proposal
  • Currently we have a limit on the amount of time we can spend in const-eval, but the only way to override it is with a nightly feature.
    • See Tracking issue for const_eval_limit: configurable, per-item instruction limit for CTFE rust#67217 for the current implementation (a crate-global attribute).

[nikomatsakis]

• #71824, Check for live drops in constants after drop elaboration
  • This is enabled by moving const-checking after drop elaboration
    • Additional precision in what is availible
    • Concern: This makes drop elaboration more of the public facing languge/”spec”
  • Drop elaboration removes most frivolous Drop terminators. It seems silly to duplicate this work during const-checking.
  • Allows Option::unwrap to become (unstably) const: Can't implement a const Option::unwrap because of "destructors cannot be evaluated at compile-time" error. rust#66753
  • Does this want its own feature gate, or wrap into above? (nominated below)

[nikomatsakis]

Update from meeting:

• Check for live drops in constants after drop elaboration rust#71824 has been merged.

[nikomatsakis]

2020-06-22:

• Have the Review const evaluation skill-tree and unsafe questions #18 design meeting this week about the skill tree and unsafe and so forth.

[ecstatic-morse]

const_if_match and const_loop stabilization PR merged (rust-lang/rust#72437). On track for stabilization in 1.46.

[nikomatsakis]

2020-07-06:

• No updates we are aware of :)

[nikomatsakis]

2020-08-3:

• No updates

[joshtriplett]

2020-08-10:

• No updates

[nikomatsakis]

2020-08-31:

No updates.

[nikomatsakis]

2020-09-21:

We have entered the "const evaluatable" check that allows you to have array sizes beyond [u8; N] (e.g., [u8; N+1]), but still lots of work before that would be considered possible on stable.

[nikomatsakis]

@RalfJung opened rust-lang/rfcs#3016 with the following summary:

Define how UB during const evaluation is treated: some kinds of UB must be detected, the rest leads to an unspecified result for the affected CTFE query (but does not otherwise "taint" the compilation process).

[oli-obk]

The blog post (in the skill-tree meeting it was discussed that basically all that is missing is a blog post referencing the current status of the skill tree that the lang team will sign off on) is now also ready: rust-lang/blog.rust-lang.org#719

[RalfJung]

Status update

From my perspective, the main thing happening here that is relevant for t-lang is rust-lang/rfcs#3016. This will unblock stabilizing some unsafe operations in const fn.

There's also a bunch of work going on under the hood on the implementation side (moving towards valtrees), but at least for now these should not have any visible effects. Longer-term I think this will be a great foundation for cleaning up our "structural equality" story around consts in patterns.

[oli-obk]

rust-lang/rfcs#3016 has been merged, we can now start stabilization requests to the lang team for individual unsafe things like transmute or raw pointer derefs.

valtrees are on ice until July and look promising except for some perf things that need to be figured out

there's some discussion going on around panics with user defined messages during CTFE

explicit promotion is being removed from the compiler (rust-lang/rust#85110). It was only used for SIMD intrinsic array lengths. Instead one now needs to specify a constant item and reference that in the length argument. There's work going on to replace all of these "magic arguments that must be constant" with const generics. This should simplify the compiler further and avoid having multiple schemes that do the same thing in slightly different ways.

[RalfJung]

I am particularly happy about the last point. :D We are almost done with the multi-year effort of cleaning up the story around promotion. There is one last thread left to discuss, see rust-lang/rust#80619 for details.

[RalfJung]

Status update

rust-lang/rust#85769 has been proposed for FCP, as our first foray into wildly unsafe things inside const fn. The tricky part is that this breaks the property that const fn will be deterministic even when invoked at runtime. (However, if ptr-to-int transmutes are indeed UB at runtime, then this issue would not come up. Though one could say then we have a bigger problem. ;)

There's been some setback with panic! inside consts due to edition 2021 issues (the old hacks we used to only evaluate argumentless format strings don't work any more), but just today a new proposal to solve this was made: rust-lang/rust#86830.

There was some more talk about floats and in particular NaNs during CTFE, but again it is unknown how to avoid introducing const fn that are non-deterministic at runtime.

There might be more things, honestly I am not entirely sure.^^

[RalfJung]

Ah, I guess there's also inline consts. No progress, to my knowledge, but it would be really good to figure out what it would take to make progress here. :)

[joshtriplett]

@RalfJung It'd be helpful to make forward progress on inline consts for the benefit of inline assembly. cc @Amanieu.

[RalfJung]

Yeah, that's one reason why I brought it up.

I don't really have any free cycles to work on this though, so I am not sure how much I can do.