Use llfn_attrs_from_instance() to generate the attributes for the
allocator shim. This ensures that we generate all the usual
attributes (and don't get to find out one-by-one that a certain
attribute is important for a certain target). Additionally this
will enable emitting the allocator-specific attributes (not
included here).
This change is quite awkward because the allocator shim uses
SimpleCx, while llfn_attrs_from_instance uses CodegenCx. I've
switched it to use SimpleCx plus tcx/sess arguments where necessary.
If there's a simpler way to do this, I'd love to know about it...
Add panic=immediate-abort
MCP: https://github.com/rust-lang/compiler-team/issues/909
This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts.
In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`.
The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large.
`-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing.
The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature.
To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it.
I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
Add self-profile events for target-machine creation
These code paths are surprisingly hot in the `large-workspace` benchmark (e.g. see perf changes from rust-lang/rust#146700), suggesting room for more improvement. It would be handy to see some detailed timings and execution counts.
cg_llvm: Move target machine command-line quoting from C++ to Rust
When this code was introduced in rust-lang/rust#130446 and rust-lang/rust#131805, it was complicated by the need to maintain compatibility with earlier versions of LLVM.
Now that LLVM 20 is the baseline (rust-lang/rust#145071), we can do all of the quoting in pure Rust code, and pass two flat strings to LLVM to be used as-is.
---
In this PR, my priority has been to preserve the existing behaviour as much as possible, without worrying too much about what the behaviour *should* be. (Though I did avoid a leading space before the first argument.)
rustc_codegen_llvm: Feature Conversion Tidying
The author thinks we can improve `to_llvm_features`, a function to convert a Rust target feature name into an LLVM feature (or nothing, to ignore features unsupported by LLVM) for better maintainability.
1. We can simplify some clauses and some expressions.
2. There are some readability issues.
This PR attempts to resolve some of them by tidying many cases.
Prevent ABI changes affect EnzymeAD
This PR handles ABI changes for autodiff input arguments to improve Enzyme compatibility. Fundamentally this adjusts activities when a function argument is lowered as an `ScalarPair`, so there's no mismatch between diff activities and args. Also removes activities corresponding to ZSTs.
fixes: https://github.com/rust-lang/rust/issues/144025
r? `@ZuseZ4`
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 4)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#146631
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
Make llvm_enzyme a regular cargo feature
This makes it clearer that it is set by the build system rather than by the rustc that compiles the current rustc. It also avoids bootstrap needing to pass `--check-cfg llvm_enzyme` to rustc.
Remove unsized arg handling in `ArgAbiBuilderMethods::store_fn_arg` implementations
... since it is unreachable and would ICE anyway.
These branches are unreachable with how `store_fn_arg` is currently used (where it is called, unsized arguments are either: 1. not (yet) supported, or 2. handled differently)[^1], and even if they were reachable, they would ICE anyway, since they call [`OperandValue::store`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#855-861), which calls [`OperandValue::store_with_flags`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#887-926) which [panics on any unsized layout](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#900-903).
Also updates the `bug!` message in `store_arg` to not suggest `store_fn_arg` for unsized args.
[^1]: `store_fn_arg` is only nontrivially[^2] called in `compiler/rustc_codegen_ssa/src/mir/mod.rs` for: Line 428 `extern "rust-call"` tuple (un)splitting, which does not support unsized arguments, Line 496 which is only for sized `PassMode::Indirect` (`meta_attrs: None`) arguments, and Line 521 which is only for non-`PassMode::Indirect` arguments which can never be unsized.
[^2]: `<Bx as ArgAbiBuilderMethods>::store_fn_arg` is what is actually called, but codegen_llvm and codegen_gcc's builders both delegate to their own `codegen_crate::ArgAbiExt::store_fn_arg`, which contain the actual implementations that are changed in this PR.
This commit simplifies construction of `arch` from `sess.target.arch`.
It also preserves a reference to `sess.target.arch` as `raw_arch`
to make this function future proof.
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 3)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#136375
- Follow-up to rust-lang/rust#136632
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
This PR migrates all of the bindings that were touched by rust-lang/rust#136632, plus `LLVMDIBuilderCreateStructType`.
initial implementation of the darwin_objc unstable feature
Tracking issue: https://github.com/rust-lang/rust/issues/145496
This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.
r? ```@tmandry```
try-job: `*apple*`
try-job: `x86_64-gnu-nopt`
