target specs: stricter checks for LLVM ABI values, and correlate that with cfg(target_abi)
This tightens the checks for `llvm_abiname`, `llvm_floatabi` and `rustc_abi` in our target specs. Those are the fields that actually control the ccABI. With this commit, we now have an allowlist of value for these fields for all architectures (we previously only had that for some architectures). We also check that `cfg(target_abi)` suitably correlates with the actual ccABI. I based this check on our in-tree targets. For all ccABIs where we had a bunch of "random" values that don't directly correlate to the ccABI (like "uwp"), I also allowed `cfg(target_abi)` to remain empty, and whenever it is allowed to be empty I also allowed arbitrary other values for JSON targets. However, there's still a risk that JSON targets will fail this new check -- the idea is that we'll then get bugreports and can adjust the check as needed.
I had to adjust the target specs for non-ARM32 Apple targets as those were all setting `llvm_floatabi`, which to my knowledge makes no sense -- LLVM only actually does anything with that field on ARM32. I also adjusted the target specs for MIPS32 targets: one of them was setting llvm_abiname, and then it seems safer and more consistent to set that for all targets, so I set it to "o32" everywhere which seems to be the default.
Cc @workingjubilee
- Hide common linker output behind `linker-info`
- Add tests
- Account for different capitalization on windows-gnu when removing
"warning" prefix
- Add some more comments
- Add macOS deployment-target test
- Ignore linker warnings from trying to statically link glibc
I don't know what's going on in `nofile-limit.rs` but I want no part
of it.
- Use a fake linker so tests are platform-independent
This is already CodegenResults without CrateInfo. The driver can
calculate the CrateInfo and pass it by-ref to the backend. Using
CompiledModules makes it a bit easier to move some other things out of
the backend as will be necessary for moving LTO to the link phase.
Simplify ThinLTO handling
This reduces the amount of complexity around ThinLTO module buffers. It removes duplication between `ModuleBuffer` and `ThinBuffer` (the latter was also used for fat LTO in some cases), clarifies when and where the ThinLTO summary is used (only for `--emit thin-link-bitcode`, ThinLTO performed by rustc rebuilds the summary every time). This also enables a follow up cleanup to reduce code duplication between red, green and imported codegen units.
Part of https://github.com/rust-lang/compiler-team/issues/908
Start migration for `LintDiagnostic` items by adding API and migrating `LinkerOutput` lint
This is more or less the same approach as https://github.com/rust-lang/rust/pull/152811, but in a much smaller size to make it reviewable. A lot of PRs will follow though. :)
This PR creates the equivalent of `lint_level` working with `Diagnostic` and add new methods on `MultiSpan` to make it work as well (in particular because we need to copy messages/spans from one context to another).
r? @JonathanBrouwer
As far as I can tell it was introduced to allow fat LTO with
-Clinker-plugin-lto. Later a change was made to automatically disable
ThinLTO summary generation when -Clinker-plugin-lto -Clto=fat is used,
so we can safely remove it.
Windows binaries are always position independent
and Clang warns when trying to enable or disable
that:
```
❯ clang hello.c -pie
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
❯ clang hello.c -no-pie
clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
```
Remove some unnecessary `try`-related type annotations
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think they should be left alone.
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think seeing the type would be better.
This makes cdylibs compile to working Emscripten dynamic libraries without passing extra
RUSTFLAGS. This was previously approved as PR 98358 but there were CI failures that I
never got around to fixing.
Stuart Cook