Remove support for decompressing dylib metadata
We haven't been compressing dylib metadata for a while now. Removing decompression support will regress error messages about an incompatible rustc version being used, but dylibs are pretty rare anyway.
Fixes https://github.com/rust-lang/rust-analyzer/issues/18451
Use protected visibility when building rustc with LLD
https://github.com/rust-lang/compiler-team/issues/782
I wasn't sure about having two commits in a PR, but I figured, at least initially it might make sense to discuss these commits together. Happy to squash, or move the second commit to a separate PR.
I contemplated trying to enable protected visibility for more cases when LLD will be used other than just `-Zlinker-features=+lld`, but that would be more a complex change that probably still wouldn't cover all cases when LLD is used, so went with the simplest option of just checking if the linker-feature is enabled.
r? lqd
llvm: Match new LLVM 128-bit integer alignment on sparc
LLVM continues to align more 128-bit integers to 128-bits in the data layout rather than relying on the high level language to do it. Update SPARC target files to match and add a backcompat replacement for current LLVMs.
See llvm/llvm-project#106951 for details
`@rustbot` label: +llvm-main
r? `@durin42`
(Please wait for the LLVM CI to come back before approving), creating this PR to get it tested there.
Remove `""` case from RISC-V `llvm_abiname` match statement
For RISC-V, `""` isn't the always the same ABI as `"ilp32"`/`"lp64"` (`""` means LLVM will infer the ABI based on the enabled target features), but `create_object_file` currently assumes that it is. Since all RISC-V targets explicitly specify their ABI since #131807, this PR removes `""` from the match arm's pattern (meaning an empty string will now fall through to the `_ => bug!` arm).
r? `@workingjubilee`
macOS: Document the difference between Clang's `-darwin` and `-macosx` targets
`rustc`'s `*-apple-darwin` targets are badly named (they should've been called `*-apple-macos`), and this causes confusion wrt. the similarly named but somewhat incompatible Clang targets.
So let's document the difference to at least make things a _little_ easier on our users.
``@rustbot`` label O-macos A-docs
continue `TypingMode` refactor
There are still quite a few places which (indirectly) rely on the `Reveal` of a `ParamEnv`, but we're slowly getting there
r? `@compiler-errors`
compiler: Move `rustc_target::spec::abi::Abi` to `rustc_abi::ExternAbi`
Lift `enum Abi` from its rather odd place in the middle of rustc_target, and make it available again from rustc_abi. You know, the crate where you would expect the enum that describes all the ABIs to be? The platform-neutral ones, at least. This will help further refactoring of how we handle ABIs in the near future[^0].
Rename `Abi` to `ExternAbi` because quite a lot of the compiler overloads the concept of "ABI" enough that the existing name is imprecise and it is often renamed _anyway_. Often this was to avoid conflicts with the *other* type formerly known as `Abi` (now named BackendRepr[^1]), but sometimes it is just for clarity, and this name seems more self-explanatory. It does get reexported, though, using its old name, to reduce the odds of merge-conflicting over the entire tree.
All of `ExternAbi`'s friends come along for the ride, which costs adding some optional dependencies to the rustc_abi crate. However, all of this also allows simply moving three crates entirely off rustc_target:
- rustc_hir_pretty
- rustc_lint_defs
- rustc_mir_build
This odd selection is mostly to demonstrate a secondary motivation: The majority of the front-end of the compiler should be as target-agnostic as possible, and it is easier to assure this if they simply don't depend on the crate that describes targets. Note that I didn't migrate crates that don't benefit from it in this way yet, and I didn't survey every last crate.
[^0]: This is being undertaken as part of https://github.com/rust-lang/rust/issues/119183
[^1]: https://github.com/rust-lang/rust/pull/132246
Improve missing_abi lint
This is for the migration lint for https://github.com/rust-lang/rfcs/pull/3722
It is not yet marked as an edition migration lint, because `Edition2027` doesn't exist yet.
The lint now includes a machine applicable suggestion:
```
warning: extern declarations without an explicit ABI are deprecated
--> src/main.rs:3:1
|
3 | extern fn a() {}
| ^^^^^^ help: explicitly specify the C ABI: `extern "C"`
|
```
