This causes it to be called even when passing `-Zno-link`, when linking
fails or when neither `--emit link` nor `--emit metadata` is used.

This also moves the -Zno-link implementation to rustc_interface

This makes it also run when compilation has failed, neither --emit exe
nor --emit metadata is passed, or -Zno-link is used.

This is a solution to the file length being over 3000, something Clippy has a problem with.

The other solution to the file length is
1. to change the API of this struct by
2. encapulating certain fields of the struct into other structs.

This gives greater type safety and is less work to maintain on the
rustdoc end.

Rustdoc's ordering requirements are probably not relevant to the rest of
the compiler.

The assignment of `features` above was added in rust-lang#60981, but
never used. Presumably the intent was to replace the string literal here
with it.

While I'm in the area, `compiler_builtins_c_feature` doesn't need to be
a `String`.

Certain platforms need to limit the DWARF version emitted (oxs, *bsd). This
change adds a dwarf_version entry to the options that allows a platform to
specify the dwarf version to use. By default this option is none and the default
DWARF version is selected.

Also adds an option for printing Option<u32> json keys

Add LLVM flags to limit DWARF version to 2 on BSD

This has been a thorn in my side for a while, I can finally generate flamegraphs of rust programs on bsd again. This fixes dtrace profiling on freebsd, I think it might help with lldb as well but I can't test that because my current rust-lldb setup is messed up.

I'm limiting the dwarf version to 2 on all bsd's (netbsd/openbsd/freebsd) since it looks like this applies to all of them, but I have only tested on freebsd.

Let me know if there's anything I can improve!

---
Currently on FreeBSD dtrace profiling does not work and shows jumbled/incorrect
symbols in the backtraces. FreeBSD does not support the latest versions of DWARF
in dtrace (and lldb?) yet, and needs to be limited to DWARF2 in the same way as macos.

This adds an is_like_bsd flag since it was missing. NetBSD/OpenBSD/FreeBSD all
match this.

This effectively copies rust-lang#11864 but targets FreeBSD instead of macos.

…imulacrum

BTreeMap: fix gdb provider on BTreeMap with ZST keys or values

Avoid error when gdb is asked to inspect a BTreeMap or BTreeSet with a zero-sized type as key or value. And clean up.

r? @Mark-Simulacrum

…factor, r=oli-obk

Codegen backend interface refactor

This moves several things away from the codegen backend to rustc_interface. There are a few behavioral changes where previously the incremental cache (incorrectly) wouldn't get finalized, but now it does. See the individual commit messages.

…hewjasper

Moved the main `impl` for FnCtxt to its own file.

Resolves rust-lang#77085 without breaking the API of the `FnCtxt` struct.

This is a solution to the file length being over 3000 (see issue rust-lang#60302).

The other solution to the file length is
1. to change the API of this struct by
2. encapulating certain fields of the struct into other structs.

Switch rustdoc from `clean::Stability` to `rustc_attr::Stability`

This gives greater type safety and is less work to maintain on the rustdoc end. It also makes rustdoc more consistent with rustc.
Noticed this while working on rust-lang#76998.

- Remove `clean::Stability` in favor of `rustc_attr::Stability`
- Remove `impl Clean for Stability`; it's no longer necessary

r? @GuillaumeGomez
cc @petrochenkov

…lexcrichton

bootstrap: only use compiler-builtins-c if they exist

The assignment of `features` above was added in rust-lang#60981, but
never used. Presumably the intent was to replace the string literal here
with it.

While I'm in the area, `compiler_builtins_c_feature` doesn't need to be
a `String`.

I'm not entirely sure of a great way to locally test this -- `./x.py test`
passed on my machine, but 🤷‍♂️.

r? @alexcrichton

Use intra-doc links for links to module-level docs

r? @jyn514

…r=jyn514

Move `Strip` into a separate rustdoc pass

Just something which was bothering me lately. :)

r? @jyn514