compiler_builtins

[jethrogb]

"it needs to disappear" from the perspective of the user.

Quoting @japaric https://github.com/rust-lang-nursery/embedded-wg/issues/64

In no_std programs you have to explicitly link to the compiler_builtins crate or at least one of your dependencies has to. The std crate depends on compiler_builtins so you don't need a explicit extern crate compiler_builtins in std programs.

compiler_builtins is an implementation detail of the LLVM backend and no Rust user should ever need to deal with it. Ideally if you link to core then compiler_builtins should also be linked in but it's complicated.

The LLVM interface demands that the compiler intrinsics in compiler_builtins are linked in as a separate object file and that such object file is passed as the last object file argument to the linker. The compiler_builtins crate is marked with a special attribute (#![compiler_builtins], iirc) so that this holds true even in the presence of LTO (where you would expect a single object file to be produced -- due to compiler_builtins you end with two object files).

Furthermore compiler_builtins depends on core so you can't make core depend on compiler_builtins; also the core crate isn't suppose to have any dependency. The separate object file requirement also means that compiler_builtins can't be merged into core. This means that even if you don't need anything other than core you still have to depend on the forever unstable compiler_builtins crate to build a no_std binary.

I don't know what are the plans of the portability WG wrt to the compiler_builtins crate (it can't be merged into std for the same reason it can't be merged into core) but from our point of view it needs to disappear (*) (easier said than done) as it ties development of no_std binaries to the nightly channel.

(*) iirc, @eddyb had some ideas to put the compiler intrinsics in core while preserving the requirement of a separate object file but I don't remember the details.

[Ericson2314]

Core and compiler_builtins are a cyclic dependency, unless we want to get really fancy about two Cores the deepest without any software-provided operations.

Rlibc for LLVM is similar.

[eddyb]

The idea for separate object file is an attribute on the relevant functions. Should be trivial nowadays by putting them in a specific separate codegen unit.

cc @michaelwoerister

[japaric]

Opened rust-lang/rust#49380 to track merging compiler-builtins into core using the approach @eddyb mentioned.