make `tidy-alphabetical` use a natural sort
The idea here is that these lines should be correctly sorted, even though a naive string comparison would say they are not:
```
foo2
foo10
```
This is the ["natural sort order"](https://en.wikipedia.org/wiki/Natural_sort_order).
There is more discussion in [#t-compiler/help > tidy natural sort](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tidy.20natural.20sort/with/519111079)
Unfortunately, no standard sorting tools are smart enough to to this automatically (casting some doubt on whether we should make this change). Here are some sort outputs:
```
> cat foo.txt | sort
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -n
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -V
foo
foo1
foo2
foo10
mp
mp1e2
np1e2",
np",
```
Disappointingly, "numeric" sort does not actually have the behavior we want. It only sorts by numeric value if the line starts with a number. The "version" sort looks promising, but does something very unintuitive if you look at the final 4 values. None of the other options seem to have the desired behavior in all cases:
```
-b, --ignore-leading-blanks ignore leading blanks
-d, --dictionary-order consider only blanks and alphanumeric characters
-f, --ignore-case fold lower case to upper case characters
-g, --general-numeric-sort compare according to general numerical value
-i, --ignore-nonprinting consider only printable characters
-M, --month-sort compare (unknown) < 'JAN' < ... < 'DEC'
-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)
-n, --numeric-sort compare according to string numerical value
-R, --random-sort shuffle, but group identical keys. See shuf(1)
--random-source=FILE get random bytes from FILE
-r, --reverse reverse the result of comparisons
--sort=WORD sort according to WORD:
general-numeric -g, human-numeric -h, month -M,
numeric -n, random -R, version -V
-V, --version-sort natural sort of (version) numbers within text
```
r? ```@Noratrieb``` (it sounded like you know this code?)
Refresh module-level docs for `rustc_target::spec`
We have long since gone on a curveball from the flexible-target-specification RFC by introducing stability and soundness promises to the language and compiler which we often struggle with extending to target-specific implementation details. Indeed, we often *literally cannot*. We also have modified the search algorithm details. Update the comments for `rustc_target::spec` considerably.
Set elf e_flags on ppc64 targets according to abi
(This PR contains the non user-facing changes of https://github.com/rust-lang/rust/pull/142321)
Fixes https://github.com/rust-lang/rust/issues/85589 by making sure that ld.lld errors out instead of generating a broken binary.
Basically the problem is that ld.lld assumes that all ppc64 object files with e_flags=0 are object files which use the ELFv2 ABI (this here is the check https://github.com/llvm/llvm-project/blob/main/lld/ELF/Arch/PPC64.cpp#L639).
This pull request sets the correct e_flags to indicate the used ABI so ld.lld errors out when encountering ELFv1 ABI files instead of generating a broken binary.
For example compare code generation for this program (file name ``min.rs``):
```rust
#![feature(no_core, lang_items, repr_simd)]
#![crate_type = "bin"]
#![no_core]
#![no_main]
#[lang = "sized"]
trait Sized {}
#[lang = "copy"]
trait Copy {}
#[lang = "panic_cannot_unwind"]
pub fn panic() -> ! {
loop {}
}
pub fn my_rad_unmangled_function() {
loop {}
}
pub fn my_rad_function() {
loop {}
}
#[no_mangle]
pub fn _start() {
my_rad_unmangled_function();
my_rad_function();
}
```
Compile with ``rustc --target=powerpc64-unknown-linux-gnu -C linker=ld.lld -C relocation-model=static min.rs``
Before change:
```
$ llvm-objdump -d min
Disassembly of section .text:
000000001001030c <.text>:
...
10010334: 7c 08 02 a6 mflr 0
10010338: f8 21 ff 91 stdu 1, -112(1)
1001033c: f8 01 00 80 std 0, 128(1)
10010340: 48 02 00 39 bl 0x10030378 <_ZN3min25my_rad_unmangled_function17h7471c49af58039f5E>
10010344: 60 00 00 00 nop
10010348: 48 02 00 49 bl 0x10030390 <_ZN3min15my_rad_function17h37112b8fd1008c9bE>
1001034c: 60 00 00 00 nop
...
```
The branch instructions ``bl 0x10030378`` and ``bl 0x10030390`` are jumping into the ``.opd`` section which is data. That is a broken binary (because fixing those branches is the task of the linker).
After change:
```
error: linking with `ld.lld` failed: exit status: 1
|
= note: "ld.lld" "/tmp/rustcNYKZCS/symbols.o" "<1 object files omitted>" "--as-needed" "-L" "/tmp/rustcNYKZCS/raw-dylibs" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "<sysroot>/lib/rustlib/powerpc64-unknown-linux-gnu/lib" "-o" "min" "--gc-sections" "-z" "relro" "-z" "now"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: ld.lld: error: /tmp/rustcNYKZCS/symbols.o: ABI version 1 is not supported
```
Which is correct because ld.lld doesn't support ELFv1 ABI.
Apply ABI attributes on return types in `rustc_codegen_cranelift`
- The [x86-64 System V ABI standard](https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build) doesn't sign/zero-extend integer arguments or return types.
- But the de-facto standard as implemented by Clang and GCC is to sign/zero-extend arguments to 32 bits (but not return types).
- Additionally, Apple targets [sign/zero-extend both arguments and return values to 32 bits](https://developer.apple.com/documentation/xcode/writing-64-bit-intel-code-for-apple-platforms#Pass-arguments-to-functions-correctly).
- However, the `rustc_target` ABI adjustment code currently [unconditionally extends both arguments and return values to 32 bits](e703dff8fe/compiler/rustc_target/src/callconv/x86_64.rs (L240)) on all targets.
- This doesn't cause a miscompilation when compiling with LLVM as LLVM will ignore the `signext`/`zeroext` attribute when applied to return types on non-Apple x86-64 targets.
- Cranelift, however, does not have a similar special case, requiring `rustc` to set the argument extension attribute correctly.
- However, `rustc_codegen_cranelift` doesn't currently apply ABI attributes to return types at all, meaning `rustc_codegen_cranelift` will currently miscompile `i8`/`u8`/`i16`/`u16` returns on x86-64 Apple targets as those targets require sign/zero-extension of return types.
This PR fixes the bug(s) by making the `rustc_target` x86-64 System V ABI only mark return types as sign/zero-extended on Apple platforms, while also making `rustc_codegen_cranelift` apply ABI attributes to return types. The RISC-V and s390x C ABIs also require sign/zero extension of return types, so this will fix those targets when building with `rustc_codegen_cranelift` too.
r? `````@bjorn3`````
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features
`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.
Also this PR forbids to specify those target features manually (warning).
Issue: rust-lang/rust#116852
Stabilize keylocker
This PR stabilizes the feature flag `keylocker_x86` (tracking issue rust-lang/rust#134813).
# Public API
The 2 `x86` target features `kl` and `widekl`, and the associated intrinsics in stdarch.
These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 11 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.
Also, these were added way back in LLVM12, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
# Associated PRs
- rust-lang/rust#134814
- rust-lang/stdarch#1706
- rust-lang/rust#136831 (stdarch submodule update)
- rust-lang/stdarch#1795 (stabilizing the runtime detection and intrinsics)
- rust-lang/rust#141964 (stdarch submodule update for the stabilization of the runtime detection and intrinsics)
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.
cc ````@rust-lang/lang````
cc ````@rust-lang/libs-api```` for the intrinsics and runtime detection
I don't think anyone else worked on this feature, so no one else to ping, maybe cc ````@Amanieu.```` I will send the reference pr soon.
Stabilize `sha512`, `sm3` and `sm4` for x86
This PR stabilizes the feature flag `sha512_sm_x86` (tracking issue rust-lang/rust#126624).
# Public API
The 3 `x86` target features `sha512`, `sm3` and `sm4`, and the associated intrinsics in stdarch.
These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 10 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.
Also, these were added in LLVM17, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
# Associated PRs
- rust-lang/rust#126704
- rust-lang/stdarch#1592
- rust-lang/stdarch#1790
- rust-lang/rust#140389 (stdarch submodule update)
- rust-lang/stdarch#1796 (stabilizing the runtime detection and intrinsics)
- rust-lang/rust#141964 (stdarch submodule update for the stabilization of the runtime detection and intrinsics)
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.
cc `@rust-lang/lang`
cc `@rust-lang/libs-api` for the intrinsics and runtime detection
I don't think anyone else worked on this feature, so no one else to ping, maybe cc `@Amanieu.` I will send the reference pr soon.
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
store `target.min_global_align` as an `Align`
Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
compiler: set Apple frame pointers by architecture
All Apple targets stop overriding this configuration and instead use the default base of FramePointer::NonLeaf, which means some Apples will have less frame pointers in leaf functions.
r? ``@madsmtm``
cc ``@thomcc``
Apple targets can now overriding this configuration and instead use the
default based on their architecture, which means aarch64 targets now
have less frame pointers in leaf functions.
x86 (32/64): go back to passing SIMD vectors by-ptr
Fixes https://github.com/rust-lang/rust/issues/139029 by partially reverting https://github.com/rust-lang/rust/pull/135408 and going back to passing SIMD vectors by-ptr on x86. Sadly, by-val confuses the LLVM inliner so much that it's not worth it...
Also fixes https://github.com/rust-lang/rust/issues/141848 by no longer actually using vector registers with the "Rust" ABI.
r? `@tgross35`
Cc `@nikic`
try-job: `test-various*`
try-job: dist-i586-gnu-i586-i686-musl
try-job: x86_64-gnu-nopt
try-job: `x86_64-msvc*`
try-job: `i686-msvc*`
