Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#144592 (generate list of all variants with `target_spec_enum`)
- rust-lang/rust#146762 (Fix and provide instructions for running test suite on Apple simulators)
- rust-lang/rust#146770 (fixes for numerous clippy warnings)
- rust-lang/rust#146774 (Allow running `x <cmd> <path>` from a different directory)
- rust-lang/rust#146800 (Fix unsupported `std::sys::thread` after move)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix unsupported `std::sys::thread` after move
Fixes building std for any platform with an unsupported thread abstraction. This includes {aarch64,armv7,x86_64}-unknown-trusty and riscv32im-risc0-zkvm-elf, which explicitly include the unsupported module, and platforms with no PAL.
Bug fix for rust-lang/rust#145177 (std: move thread into sys).
Also fix the `std` build for xtensa, which I incidentally found while looking for an unsupported platform.
r? ``@joboet``
Fix and provide instructions for running test suite on Apple simulators
The following now works:
```sh
./x test --host='' --target aarch64-apple-ios-sim --skip tests/debuginfo
./x test --host='' --target aarch64-apple-tvos-sim --skip tests/debuginfo
./x test --host='' --target aarch64-apple-watchos-sim --skip tests/debuginfo
./x test --host='' --target aarch64-apple-visionos-sim --skip tests/debuginfo
```
I have documented the setup I used [in the `rustc-dev-guide`](https://rustc-dev-guide.rust-lang.org/tests/running.html#testing-on-emulators), it's fairly standard use of `remote-test-server` (with a small fix to library load paths which I've made in the first commit).
I first tried the somewhat simpler `target.aarch64-apple-ios-sim.runner = "xcrun simctl spawn $UDID"`, but that doesn't work as required libraries etc. also need to be copied to the device.
The debuginfo tests fail, I think because the debug info in `.dSYM` isn't available. I am yet unsure exactly how to fix this, either we need to copy that directory to the target as well, or we need to configure `lldb` somehow to read it from the host.
I decided to not add this to our CI, since I suspect we wouldn't gain much from it? Running on the simulator still uses the host Darwin kernel, it's basically just configured to run in another mode with more restricted permissions and different system libraries.
r? jieyouxu
CC ``@simlay,`` you're a lot more familiar with `xcrun simctl` than I.
Simplify default value of `download-ci-llvm`
Just set it to true, rather than having different default values on CI and locally, and then only deny `true` on our own CI, not elsewhere.
Closes: https://github.com/rust-lang/rust/issues/146768
r? `@jieyouxu`
Fixes building std for any platform with an unsupported thread
abstraction. This includes {aarch64,armv7,x86_64}-unknown-trusty and
riscv32im-risc0-zkvm-elf, which explicitly include the unsupported
module, and platforms with no PAL.
Bug fix for PR 145177 (std: move thread into sys).
add `[const] PartialEq` bound to `PartialOrd`
This change is included for discussion purposes.
The PartialOrd bound on PartialEq is not strictly necessary. It is, rather, logical: anything which is orderable should by definition have equality. Is the same true for constness? Should every type which is const orderable also have const equality?
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
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.)
std: Fix WASI implementation of `remove_dir_all`
This commit is a change to the WASI-specific implementation of the `std::fs::remove_dir_all` function. Specifically it changes how directory entries are read of a directory-being-deleted to specifically buffer them all into a `Vec` before actually proceeding to delete anything. This is necessary to fix an interaction with how the WASIp1 `fd_readdir` API works to have everything work out in the face of mutations while reading a directory.
The basic problem is that `fd_readdir`, the WASIp1 API for reading directories, is not a stateful read of a directory but instead a "seekable" read of a directory. Its `cookie` argument enables seeking anywhere within the directory at any time to read further entries. Native host implementations do not have this ability, however, which means that this seeking property must be achieved by re-reading the directory. The problem with this is that WASIp1 has under-specified semantics around what should happen if a directory is mutated between two calls to `fd_readdir`. In essence there's not really any possible implementation in hosts except to read the entire directory and support seeking through the already-read list. This implementation is not possible in the WASIp1-to-WASIp2 adapter that is primarily used to create components for the `wasm32-wasip2` target where it has constrained memory requirements and can't buffer up arbitrarily sized directories. There's some more detailed discussion at https://github.com/bytecodealliance/wasmtime/issues/11701#issuecomment-3299957213 as well.
The WASIp1 API definitions are effectively "dead" now at the standards level meaning that `fd_readdir` won't be changing nor will a replacement be coming. For the `wasm32-wasip2` target this will get fixed once filesystem APIs are updated to use WASIp2 directly instead of WASIp1, making this buffering unnecessary. In essence while this is a hack it's sort of the least invasive thing that works everywhere for now. I don't think this is viable to fix in hosts so guests compiled to wasm are going to have to work around it by not relying on any guarantees about what happens to a directory if it's mutated between reads.
Allow windows resource compiler to be overridden
In rust-lang/rust#146018, it is now required to provide a resource compiler on windows when compiling rust. This allows toolchain builders to explicitly provide a path to an alternative, such as llvm-rc, instead of the one that's provided by the Windows SDK.
cc ```@lambdageek```
`rustc_next_trait_solver`: canonical out of `EvalCtxt`
we need to canonicalize outside of the trait solver as well, so it's just a lot nicer if canonicalization is more easily accessible
if you review it commit by commit the move is properly shown
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.
std: simplify host lookup
The logic for splitting up a string into a hostname and port is currently duplicated across (nearly) all of the networking implementations in `sys`. Since it does not actually rely on any system internals, this PR moves it to the `ToSocketAddr` implementation for `&str`, making it easier to discover and maintain.
On the other hand, the `ToSocketAddr` implementation (or rather the `resolve_socket_addr` function) contained logic to overwrite the port on the socket addresses returned by `LookupHost`, even though `LookupHost` is already aware of the port and sets the port already on Xous. This PR thus removes this logic by moving the responsibility of setting the port to the system-specific `LookupHost` implementation.
As a consequence of these changes, there remains only one way of creating `LookupHost`, hence I've removed the `TryFrom` implementations in favour of a `lookup_host` function, mirroring other, public iterator-based features.
And finally, I've simplified the parsing logic responsible for recognising IP addresses passed to `<(&str, u16)>::to_socket_addrs()` by using the `FromStr` impl of `IpAddr` rather than duplicating the parsing for both IP versions.
GVN: stop hashing opaque values
GVN generates values that are not meant to be unified with any other. For instance `Opaque` (aka we don't know anything), non-deterministic constants and borrows.
The current algorithm generates a unique index, so the generated `Value` will be different from all the existing. This is wasteful, as we should not hash that `Value` at all.
This PR proposes to do this. This involves partially reimplementing a `FxIndexSet`, but yields a small but consistent perf improvement (https://github.com/rust-lang/rust/pull/145737#issuecomment-3276951054).
