rustc_target: Refactor away `TargetResult`
Follow-up to https://github.com/rust-lang/rust/pull/77202.
Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary.
The second commit contains some further cleanup based on built-in target construction being infallible.
With this change, it's possible to build on a linux-gnu target and pass
RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a
`.cargo/config.toml` file, and get a statically linked executable.
This requires libc 0.2.79, which adds support for static linking with
glibc.
Add `crt_static_respected` to the `linux_base` target spec.
Update `android_base` and `linux_musl_base` accordingly. Avoid enabling
crt_static_respected on Android platforms, since that hasn't been
tested.
Defer Apple SDKROOT detection to link time.
This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time, instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster.
This also removes the note in the platform support documentation about these targets being missing. When I wrote it, I misunderstood how the SDKROOT stuff worked.
Notes:
* This means that JSON spec targets can't explicitly override these flags. I think that is probably fine, as I believe the value is generally required, and can be set with the SDKROOT environment variable.
* This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also, `x86_64-apple-tvos` seems broken in general, and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps, but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements).
* I'm tempted to remove the use of `Result` for built-in target definitions, since I don't think they should be fallible. This was added in https://github.com/rust-lang/rust/pull/34980, but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now, or not.
Fixes#36156Fixes#76584
might_permit_raw_init: also check aggregate fields
This is the next step for https://github.com/rust-lang/rust/issues/66151: when doing `mem::zeroed`/`mem::uninitialized`, also recursively check fields of aggregates (except for arrays) for whether they permit zero/uninit initialization.
This patch also:
* Add soft-float supports: only f32
* zero-extend i8/i16 to i32 because MIPS only supports register-length
arithmetic.
* Update table in asm! chapter in unstable book.
Return values up to 128 bits in registers
This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers, just like the System V ABI.
The result is that these methods from the comment linked above now generate the same code, making the Rust ABI as efficient as the `"C"` ABI:
```rust
pub struct Stats { x: u32, y: u32, z: u32, }
pub extern "C" fn sum_c(a: &Stats, b: &Stats) -> Stats {
return Stats {x: a.x + b.x, y: a.y + b.y, z: a.z + b.z };
}
pub fn sum_rust(a: &Stats, b: &Stats) -> Stats {
return Stats {x: a.x + b.x, y: a.y + b.y, z: a.z + b.z };
}
```
```asm
sum_rust:
movl (%rsi), %eax
addl (%rdi), %eax
movl 4(%rsi), %ecx
addl 4(%rdi), %ecx
movl 8(%rsi), %edx
addl 8(%rdi), %edx
shlq $32, %rcx
orq %rcx, %rax
retq
```
Late link args order
MSYS2 changed how winpthreads is built and as the result it now depends on more mingw-w64 libraries.
This PR affects only MinGW targets since nobody else is using `late_link_args_{dynamic,static}`. Now the order is similar to how it used to be before https://github.com/rust-lang/rust/pull/67502.
