Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#149744 (test: update duplicate many_digits test to use f64 instead of f32)
- rust-lang/rust#149946 (mir_build: Move and rename code for partitioning match candidates)
- rust-lang/rust#149987 (Move ambient cdb discovery from compiletest to bootstrap)
- rust-lang/rust#149990 (Improve amdgpu docs: Mention device-libs and xnack)
- rust-lang/rust#149994 (Allow vector types for amdgpu)
- rust-lang/rust#149997 (Link POSIX instead of Linux manual for Instant)
- rust-lang/rust#150010 (Correct library linking for hexagon targets in run-make tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Correct library linking for hexagon targets in run-make tests
Fixes the run-make test framework to use target-specific library linking instead of host-based detection. Previously, tests for hexagon targets failed because the framework used uname() to detect libraries to link, which returned Linux libraries (-lm -lrt -ldl -lpthread) that don't exist on all hexagon targets.
- Use target() instead of uname() to detect cross-compilation targets
- Add hexagon-specific library configuration (-lunwind -lclang_rt.builtins-hexagon)
- Maintain backward compatibility for host-native compilation
This enables hexagon tests to compile and link successfully with the appropriate runtime libraries for the hexagon platform.
Link POSIX instead of Linux manual for Instant
This commit changes the links in the source code that link to a platform specific implementation of the POSIX interface of `clock_gettime`, despite the respective areas in the code being specifically UNIX system agnostic, thereby making it more reasonable to link the POSIX specific document.
Allow vector types for amdgpu
The amdgpu target uses vector types in various places. The vector types can be used on all architectures, there is no associated target feature that needs to be enabled.
The largest vector type found in LLVM intrinsics is `v32i32` (`[32 x i32]`) for mfma intrinsics. Note that while this intrinsic is only supported on some architectures, the vector type itself is supported on all architectures.
Tracking issue: rust-lang/rust#135024
(I used an empty string to say “does not need a target feature”. If you prefer an `Option` or something like that, I’ll change it.)
Improve amdgpu docs: Mention device-libs and xnack
Mention amdgpu-device-libs for allocator and println support and mention the necessary target flag for GPUs from some some series without xnack support.
For the last half year, there were no major changes in the amdgpu-device-libs crate (in fact, there was no need to update the crate), so I believe it is stable enough to mention it here.
The xnack-support flag is something I stumbled upon recently, when more complex printlns failed on a certain GPU.
Tracking issue: rust-lang/rust#135024
Move ambient cdb discovery from compiletest to bootstrap
- Follow-up to https://github.com/rust-lang/rust/pull/149710
---
As with the previous PR, this PR takes the compiletest code for discovering an “ambient” `cdb` in the user's path, and moves it to bootstrap.
The discovery code is indeed questionable, but improving it is out of scope for this PR.
r? jieyouxu
mir_build: Move and rename code for partitioning match candidates
I've always found it confusing that this code uses the word “sort” to describe partitioning candidates into buckets, since it isn't *sorting* them in the usual sense.
This PR therefore renames the relevant methods:
- `sort_candidates` → `partition_candidates_into_buckets`
- `sort_candidate` → `choose_bucket_for_candidate`
In addition, this PR moves those methods into their own `buckets` module, updates some comments to reflect the renaming, and also makes `partition_candidates_into_buckets` return a named struct instead of a tuple.
There should be no change to compiler behaviour.
test: update duplicate many_digits test to use f64 instead of f32
Replace the f32 test case with an f64 equivalent to improve coverage for parsing large digit counts in double-precision floating-point conversion. Specifically, this PR updates the `many_digits` test in `library/coretests/tests/num/dec2flt/parse.rs` to test f64 (double-precision) parsing instead of f32 (single-precision).
The test verifies that decimal strings with an excessive number of digits (beyond `Decimal::MAX_DIGITS`) are parsed correctly, ensuring proper truncation of insignificant digits. Previously, the same test was repeated twice (see comment https://github.com/rust-lang/rust/pull/86761#issuecomment-3623334228 by `@Viatorus).`
## Changes
- Replaced the duplicated f32 test case with an equivalent f64 test case.
- Updated the expected bit pattern and input string to a very long decimal with many trailing zeros, testing the limits of f64 precision.
Implements proper variadic argument handling for hexagon-unknown-linux-musl
targets using a 3-pointer VaList structure compatible with LLVM's
HexagonBuiltinVaList implementation.
* Handles register save area vs overflow area transition
* Provides proper 4-byte and 8-byte alignment for arguments
* Only activates for hexagon+musl targets via Arch::Hexagon & Env::Musl
Fixes the run-make test framework to use target-specific library linking
instead of host-based detection. Previously, tests for hexagon targets
failed because the framework used uname() to detect libraries to link,
which returned Linux libraries (-lm -lrt -ldl -lpthread) that don't
exist on all hexagon targets.
- Use target() instead of uname() to detect cross-compilation targets
- Add hexagon-specific library configuration (-lunwind -lclang_rt.builtins-hexagon)
- Maintain backward compatibility for host-native compilation
This enables hexagon tests to compile and link successfully with the
appropriate runtime libraries for the hexagon platform.
don't use no_main and no_core to test IBT
The previous test was quite fragile and depended on a bunch of internal features. Simplify it.
Split out of https://github.com/rust-lang/rust/pull/149937.
cc ```@jieyouxu``` ```@Oneirical```
Cleanup of attribute parsing errors
Removes the specific `UnknownMetaItem` and `IllFormedAttributeInputLint` errors.
Note that `IllFormedAttributeInputLint` is not a lint, contrary to its name
r? ``````@jdonszelmann``````
replace addr_of_mut with &raw mut in maybeuninit docs
In the docs for `addr_of_mut` it says that the macro is "soft-deprecated" so maybe the std docs should stop recommending it.
I searched for other places where this is used, but didn't find any in public stable documentation.
std: Don't use `linkat` on the `wasm32-wasi*` targets
This commit is a follow-up to rust-lang/rust#147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
std: reorganize pipe implementations
Currently, there are two distinct types called `AnonPipe` in `std`:
* The one used to implement `io::pipe` (in `sys::anonymous_pipe`)
* The one used to implement `Stdin`/`Stdout`/`Stderr` (in `sys::pal::pipe`)
On Windows, these actually have different semantics, as one of the handles returned by the `sys::pal::pipe` version is opened for asynchronous operation in order to support `read2`, whereas the `sys::anonymous_pipe` version does not do so. Thus the naming is extremely confusing.
To fix this, this PR renames the `sys::anonymous_pipe` version of `AnonPipe` to simply `Pipe`, whereas the `sys::pal::pipe` version is now called `ChildPipe`. Additionally,
* `sys::anonymous_pipe` is now also just called `sys::pipe`.
* On Windows, `sys::pal::pipe` has been moved to `sys::process` and is now called `sys::process::child_pipe`.
* On non-Windows platforms, pipe creation is now exclusively handled by `sys::pipe` and `ChildPipe` is defined as a type alias to `Pipe` within `sys::process`.
And lastly, the `read2` function (originally in `sys::pal::pipe`) is now called `read_output` and defined by `sys::process`, as (at least on Windows) it is only usable with `ChildPipe`.
Includes rust-lang/rust#146639 for convenience.
This commit changes the links in the source code that link to a platform
specific implementation of the POSIX interface of `clock_gettime`,
despite the respective areas in the code being specifically UNIX system
agnostic, thereby making it more reasonable to link the POSIX specific
document.
The amdgpu target uses vector types in various places. The vector types
can be used on all architectures, there is no associated target feature
that needs to be enabled.
The largest vector type found in LLVM intrinsics is `v32i32`
(`[32 x i32]`) for mfma intrinsics. Note that while this intrinsic is
only supported on some architectures, the vector type itself is
supported on all architectures.
Mention amdgpu-device-libs for allocator and println support and mention
the necessary target flag for GPUs from some some series without xnack
support.
For the last half year, there were no major changes in the
amdgpu-device-libs crate (in fact, there was no need to update the
crate), so I believe it is stable enough to mention it here.
The xnack-support flag is something I stumbled upon recently, when more
complex printlns failed on a certain GPU.
