Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

const-evaluation #22

Open
nikomatsakis opened this issue Jun 11, 2020 · 21 comments
Open

const-evaluation #22

nikomatsakis opened this issue Jun 11, 2020 · 21 comments
Assignees
Labels
lang-initiative An active lang team initiative

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Jun 11, 2020

Summary

Const-evaluation, language team impact

Links

@nikomatsakis nikomatsakis self-assigned this Jun 11, 2020
@nikomatsakis nikomatsakis added the lang-initiative An active lang team initiative label Jun 11, 2020
@nikomatsakis
Copy link
Contributor Author

  • 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)

@nikomatsakis
Copy link
Contributor Author

@nikomatsakis
Copy link
Contributor Author

@nikomatsakis
Copy link
Contributor Author

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Jun 15, 2020

Update from meeting:

@nikomatsakis
Copy link
Contributor Author

2020-06-22:

@ecstatic-morse
Copy link

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

@nikomatsakis
Copy link
Contributor Author

2020-07-06:

  • No updates we are aware of :)

@nikomatsakis
Copy link
Contributor Author

2020-08-3:

  • No updates

@joshtriplett
Copy link
Member

2020-08-10:

  • No updates

@nikomatsakis
Copy link
Contributor Author

2020-08-31:

No updates.

@nikomatsakis
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link

oli-obk commented Nov 13, 2020

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
Copy link
Member

RalfJung commented Apr 10, 2021

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
Copy link

oli-obk commented May 13, 2021

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
Copy link
Member

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
Copy link
Member

RalfJung commented Jul 3, 2021

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
Copy link
Member

RalfJung commented Jul 7, 2021

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
Copy link
Member

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

@RalfJung
Copy link
Member

RalfJung commented Jul 7, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang-initiative An active lang team initiative
Projects
Status: Experimental
Development

No branches or pull requests

6 participants