Inline const_eval_select

[tmiasko]

To avoid circular link time dependency between core and compiler
builtins when building with -Zshare-generics.

r? @Amanieu

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[Amanieu]

@bors r+

[bors]

📌 Commit 8a8404b has been approved by Amanieu

[bjorn3]

Shouldn't

rust/library/core/src/num/f32.rs

Line 939 in 083721a

let rt_f32_to_u32 = |rt| unsafe { mem::transmute::<f32, u32>(rt) };

and the equivalent f64 closures be inlined too? (And preferably turned into functions to also help debug mode)

[tmiasko]

Are you referring to a situation where we would generate an internal copy of to_bits, const_eval_select in the compiler builtins but attempt to link to a closure function exported from the core? As far as I know, whenever #[inline] functions generate CGU internal copies so do the closures, so this shouldn't be possible.

And preferably turned into functions to also help debug mode

What is the implied difference between the closures and functions? And how does using functions help in debug mode?

[bjorn3]

As far as I know, whenever #[inline] functions generate CGU internal copies so do the closures, so this shouldn't be possible.

I see.

What is the implied difference between the closures and functions?

Closure calls seem to generate significantly more code: https://rust.godbolt.org/z/KaP4rKzoa Basically instead of a direct call of the closure function itself, FnOnce::call_once is called, which then calls the closure function.

And how does using functions help in debug mode?

Less llvm ir generated -> lower compile time & better runtime performance in debug mode

[tmiasko]

The extra indirection is a shim that adapts Fn / FnMut closure to FnOnce. Functions would also use a shim in this context.

[bjorn3]

I see. Would be nice to somehow remove the need for that shim in the context of const_eval_select.

[tmiasko]

If closure captures a non-copy value then it would be FnOnce and shim will be omitted. Not exactly a serious proposal, but it's possible :-).