Add const_eval_select intrinsic

[fee1-dead]

Adds an intrinsic that calls a given function when evaluated at compiler time, but generates a call to another function when called at runtime.

See rust-lang/const-eval#7 for previous discussion.

r? @oli-obk.

[rust-highfive]

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[oli-obk]

cc @rust-lang/wg-const-eval

[oli-obk]

I would like to see some tests that hit the invalid use cases that typeck is catching and thus report errors. While it is not important for intrinsics, it's still good to check that they aren't completely bonkers

[nbdd0121]

Alternative design idea #89291: have a call_if_rt

pubfncall_if_rt<R,F:FnOnce() -> R + Copy>(f:F) -> Option<R>;

that returns Some(f()) in runtime and None in compile time.

Pro:

• No changes required to typeck, codegen
• Allows everything to be written in the same function:

constfnsome_const_fn(){ifletSome(ret) = call_if_rt(|| {// runtime part}){return ret;}// const part}

Con:

• Can't handle move.

[nbdd0121]

Came up with a new idea while writing the above comment:

How about have two functions

pubfnis_const_eval() -> bool;

and

pubfncall_at_rt<R,F:FnOnce() -> R>(f:F) -> R;

which will just call f() in runtime, and abort if called in compile time.

This should have the same pro as call_if_rt that it allows no typeck, codegen changes and allows everything to be written in the same function:

constfnsome_const_fn(){if !is_const_eval(){returncall_at_rt(|| {// runtime part});}// const part}

while it could still handle move.

[RalfJung]

Seems a bit annoying to have two intrinsics. Also, const-check special handling will still be required to not subject the closure called by call_at_rt to const-check rules.

Why does this PR require such large typeck changes in the first place?

[nbdd0121]

Seems a bit annoying to have two intrinsics. Also, const-check special handling will still be required to not subject the closure called by call_at_rt to const-check rules.

Closure isn't considered const, so no changes are needed for that regard: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=2085fb30e0a126f84b16b1744901a0f7

[fee1-dead]

Both cannot handle move, which can be a limitation, and I think that we shouldn't allow closures to be used in const contexts like this. There could be hidden problems. Therefore this might be the best and the most straightforward solution we have.

I wouldn't consider being able to write them in one function a pro, IMO I think we should make this intrinsic a little bit intentionally complex and hard to use.

[oli-obk]

Both cannot handle move, which can be a limitation, and I think that we shouldn't allow closures to be used in const contexts like this. There could be hidden problems. Therefore this might be the best and the most straightforward solution we have.

Could we pick the API of this PR, but still use the lang item solution? So

#[lang = "const_eval_select"]pubfnconst_eval_select<R,F:FnOnce() -> R,G:constFnOnce() -> R>(f:F) -> R{f()}

Then the typeck change could be just checking that F and G are function items, while leaving all the rest (signature, constness, ..) to the regular typeck logic?

This would avoid touching codegen backends entirely.

[nbdd0121]

Could we pick the API of this PR, but still use the lang item solution? So

#88963 would be needed first.

#[lang = "const_eval_select"]pubfnconst_eval_select<R,F:FnOnce() -> R,G:constFnOnce() -> R>(f:F) -> R{f()}

Then the typeck change could be just checking that F and G are function items, while leaving all the rest (signature, constness, ..) to the regular typeck logic?

I don't think function item check would be necessary then.

[oli-obk]

🙈 I thought I r+ed that already...

Only allowing function items, in order to make it very explicit what is going on still stands, but it could "simply" be circumvented via const_eval_select(call_first, const_fn_call, (|x| x.stuff(), real_arg)) where fn call_first<T>((f, arg): (impl FnOnce(T), T)) {f(arg)}, so I guess you're right, we can just allow closures.

[fee1-dead]

@bors r=oli-obk

formatting fix

[bors]

📌 Commit 26b78cc has been approved by oli-obk

[fee1-dead]

@bors r-

[oli-obk]

r=me with CI passing

[fee1-dead]

@bors r=oli-obk

[bors]

📌 Commit 11fac09 has been approved by oli-obk

[bors]

⌛ Testing commit 11fac09 with merge c34ac87...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing c34ac87 to master...

[rust-timer]

Finished benchmarking commit (c34ac87): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression