[win] Use find-msvc-tools instead of cc to find the linker and rc on Windows
`find-msvc-tools` was factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) and `rustc_windows_rc` (finding the Windows Resource Compiler when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of building the Rust compiler).
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.
Enable `limit_rdylib_exports` on wasm targets
This commit updates the target specification of wasm targets to set the `limit_rdylib_exports` value to `true` like it is on other native platforms. This was originally not implemented long ago as `wasm-ld` didn't have options for symbol exports, but since then it's grown a `--export` flag and such to control this. A custom case is needed in the linker implementation to handle wasm targets as `wasm-ld` doesn't support linker scripts used on other targets, but other than that the implementation is straightforward.
The goal of this commit is enable building dynamic libraries on `wasm32-wasip2` which don't export every single symbol in the Rust standard library. Currently, without otherwise control over symbol visibility, all symbols end up being exported which generates excessively large binaries because `--gc-sections` ends up doing nothing as it's all exported anyway.
naked_asm: emit a label starting with `func_end`
The `cargo asm` tool (`cargo install cargo-show-asm`) pattern matches on such labels to figure out where functions end: normal functions generated by LLVM always do have such a label. We don't guarantee that naked functions emit such a label, but having `cargo asm` work is convenient.
https://github.com/pacak/cargo-show-asm/blob/be45f67454ad8b634246a7fc69b3c6a963ee93f1/src/asm/statements.rs#L897-L901
To make the label name unique it's suffixed with the name of the current symbol.
r? ```@Amanieu```
This commit updates the target specification of wasm targets to set the
`limit_rdylib_exports` value to `true` like it is on other native
platforms. This was originally not implemented long ago as `wasm-ld`
didn't have options for symbol exports, but since then it's grown a
`--export` flag and such to control this. A custom case is needed in the
linker implementation to handle wasm targets as `wasm-ld` doesn't
support linker scripts used on other targets, but other than that the
implementation is straightforward.
The goal of this commit is enable building dynamic libraries on
`wasm32-wasip2` which don't export every single symbol in the Rust
standard library. Currently, without otherwise control over symbol
visibility, all symbols end up being exported which generates
excessively large binaries because `--gc-sections` ends up doing nothing
as it's all exported anyway.
The `cargo asm` tool pattern matches on such labels to figure out where functions end: normal functions generated by LLVM always do have such a label. We don't guarantee that naked functions emit such a label, but having `cargo asm` work is convenient
Clean up `ty::Dynamic`
1. As a follow-up to PR rust-lang/rust#143036, remove `DynKind` entirely.
2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait`
* `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types
* `lint` contained dyn-Trait-specific diagnostics+lints only
Remove Rvalue::Len again.
Now that we have `RawPtrKind::FakeForPtrMetadata`, we can reimplement `Rvalue::Len` using `PtrMetadata(&raw const (fake) place)`.
r? ``@scottmcm``
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`
interpret: fix overlapping aggregate initialization
This fixes the problem pointed out by ````@saethlin```` in https://github.com/rust-lang/rust/issues/146383#issuecomment-3273224645.
Also clarify when exactly current de-facto MIR semantics allow overlap of the LHS and RHS in an assignment.
Make `AssocItem` aware of its impl kind
The general goal is to have fewer query dependencies by making `AssocItem` aware of its parent impl kind (inherent vs. trait) without having to query the parent def_kind.
See individual commits.
This schema is helpful for people writing custom target spec JSON. It
can provide autocomplete in the editor, and also serves as documentation
when there are documentation comments on the structs, as `schemars` will
put them in the schema.
match clang's `va_arg` assembly on arm targets
tracking issue: https://github.com/rust-lang/rust/issues/44930
For this example
```rust
#![feature(c_variadic)]
#[unsafe(no_mangle)]
unsafe extern "C" fn variadic(a: f64, mut args: ...) -> f64 {
let b = args.arg::<f64>();
let c = args.arg::<f64>();
a + b + c
}
```
We currently generate (via llvm):
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d0, r0, r1
add r0, sp, #4
vldr d1, [sp, #4]
add r0, r0, #15
bic r0, r0, #7
vadd.f64 d0, d0, d1
add r1, r0, #8
str r1, [sp]
vldr d1, [r0]
vadd.f64 d0, d0, d1
vmov r0, r1, d0
add sp, sp, #12
bx lr
```
LLVM is not doing a good job. In fact, it's well-known that LLVM's implementation of `va_arg` is kind of bad, and we implement it ourselves (based on clang) for many targets already. For arm, our own `emit_ptr_va_arg` saves 3 instructions.
Next, it turns out it's important for LLVM to explicitly start and end the lifetime of the `va_list`. In https://github.com/rust-lang/rust/pull/146059 I already end the lifetime, but when looking at this again, I noticed that it is important to also start it, see https://godbolt.org/z/EGqvKTTsK: failing to explicitly start the lifetime uses an extra register.
So, the combination of `emit_ptr_va_arg` with starting/ending the lifetime makes rustc emit exactly the instructions that clang generates::
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d16, r0, r1
vldr d17, [sp, #4]
vadd.f64 d16, d16, d17
vldr d17, [sp, #12]
vadd.f64 d16, d16, d17
vmov r0, r1, d16
add sp, sp, #12
bx lr
```
The arguments to `emit_ptr_va_arg` are based on [the clang implementation](https://github.com/llvm/llvm-project/blob/03dc2a41f3d9a500e47b513de5c5008c06860d65/clang/lib/CodeGen/Targets/ARM.cpp#L798-L844).
r? ``@workingjubilee`` (I can re-roll if your queue is too full, but you do seem like the right person here)
try-job: armhf-gnu
compiler: Add Windows resources to rustc-main and rustc_driver
Adds Windows resources with the rust version information to rustc-main.exe and rustc_driver.dll
Invokes `rc.exe` directly, rather than using one of the crates from the ecosystem to avoid adding dependencies.
A new internal `rustc_windows_rc` crate has the common build script machinery for locating `rc.exe` and constructing the resource script
Use `Itertools::all_equal_value()` where applicable
Just a small cleanup.
We already have `itertools` as a dep in these crates, so might as well use another of its features.
Makes the code simpler IMHO :)
Adds Windows resources with the rust version information to rustc-main.exe and rustc_driver.dll
Sets the product description to "Rust Compiler" or "Rust Compiler (channel)" for non-stable channels
A lot of places had special handling just in case they would get an
allocator module even though most of these places could never get one or
would have a trivial implementation for the allocator module. Moving all
handling of the allocator module to a single place simplifies things a
fair bit.
Making it participate in LTO would be incorrect if you compile a crate
as both a dylib (which needs it) and rlib (which must not include it) in
the same rustc invocation. With linker plugin LTO, the allocator shim
will still participate in LTO as it is safe to do so in that case.
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`.
Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch.
See tracking issue rust-lang/rust#145574
Stuart Cook