compiler_builtins

[jethrogb]

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

Quoting @japaric rust-embedded/wg#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.