Move all LLVM externs into the rustc_llvm crate

[Diggsey]

#17795 expresses a desire to test the LLVM bindings with ctest. A pre-requisite for that is to have all the LLVM externs in once place, rather than spread across multiple crates.

Actually testing with ctest is blocked because the current version of ctest uses a long out-of-date parser which cannot cope with eg. extern blocks among other things. However there appears to be active work to build a new version of ctest (see https://github.com/rust-lang/libc/tree/main/ctest-next)

This PR does not intend to change any behaviour, only to move all FFI code into the rustc_llvm crate so that it may be tested at some future time.

[rustbot]

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

Some changes occurred in compiler/rustc_codegen_llvm/src/builder/autodiff.rs

cc @ZuseZ4

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in compiler/rustc_codegen_llvm/src/llvm/enzyme_ffi.rs

cc @ZuseZ4

Some changes occurred in coverage instrumentation.

cc @Zalathar

[bors]

☔ The latest upstream changes (presumably #143026) made this pull request unmergeable. Please resolve the merge conflicts.

[cuviper]

I've only skimmed this so far, but I think there are a few things we can do that will reduce some of the churn.

(The smaller we can make this, the more likely I'll be able to review it properly!)

[petrochenkov]

Doing something like this was in my todo list for quite some time, but I expected to turn rustc_llvm into a crate with just bindings, a sort of typical llvm-sys.
So the dependencies on

rustc_codegen_ssa = { path = "../rustc_codegen_ssa" }
rustc_macros = { path = "../rustc_macros" }
rustc_middle = { path = "../rustc_middle" }
rustc_session = { path = "../rustc_session" }
rustc_target = { path = "../rustc_target" }

look unexpected.

[Diggsey]

@petrochenkov Types from those crates are used as part of inherent method implementations on FFI types. I could move them into extension methods or standalone functions in rustc_codegen_llvm but it would be more churn. Maybe something to address in a future PR?

[Diggsey]

I believe I've made the changes requested.

I could use some input on two things:

1. What to do regarding @petrochenkov 's comment about dependencies of rustc_llvm.
2. Any insight into this linker error I'm seeing. I can't seem to find any difference between how the two crates are built that would explain the problem?

edit:
Fixed the linker error.