Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#140983 (Improve doc of some methods that take ranges)
- rust-lang/rust#144091 (Stabilize `new_zeroed_alloc`)
- rust-lang/rust#145664 (Stabilize `std::panic::Location::file_as_c_str`)
- rust-lang/rust#146551 (fix issue with `cmse-nonsecure-entry` ABI being both async and c-variadic)
- rust-lang/rust#146744 (Deref related cleanups in ref_prop)
- rust-lang/rust#146793 (naked_asm: emit a label starting with `func_end`)
- rust-lang/rust#146820 (Add unstable attribute to BTreeMap-related allocator generics)
- rust-lang/rust#146822 (Fix old typo in lang_start_internal comment)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix old typo in lang_start_internal comment
Noticed this when reading the rt cleanup code; the typo was introduced during a mass port of libstd to std in comments.
Add unstable attribute to BTreeMap-related allocator generics
Although these types aren't directly constructable externally, since they're pub, I think this omission was an oversight.
r? libs-api
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.
be45f67454/src/asm/statements.rs (L897-L901)
To make the label name unique it's suffixed with the name of the current symbol.
r? ```@Amanieu```
fix issue with `cmse-nonsecure-entry` ABI being both async and c-variadic
tracking issue: https://github.com/rust-lang/rust/issues/75835
fixes https://github.com/rust-lang/rust/issues/132142
An `extern "cmse-nonsecure-entry"` function cannot be c-variadic (or, in any case, clang/LLVM does not support it, see https://godbolt.org/z/MaPjzGcE1). So just stop looking at the type if we know it'll be invalid anyway.
I'm not entirely sure how to test this. The ICE is only possible on the `thumbv8m.main-none-eabi` and some related targets. I think using `minicore` is the most convenient, but use of `async` requires quite a long list of lang items to be present. Maybe we want that anyway though? On the other hand, it's extra `minicore` surface that might go out of date.
An alternative is `run-make`, that should work, but is much less convenient. See also [#t-compiler/help > `async fn` and `minicore`](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60async.20fn.60.20and.20.60minicore.60/with/539427262).
r? `@ghost`
Stabilize `new_zeroed_alloc`
The corresponding `new_uninit` and `new_uninit_slice` functions were stabilized in rust-lang/rust#129401, but the zeroed counterparts were left for later out of a [desire](https://github.com/rust-lang/rust/issues/63291#issuecomment-2161039756) to stabilize only the minimal set. These functions are straightforward mirrors of the uninit functions and well-established. Since no blockers or design questions have surfaced in the past year, I think it's time to stabilize them.
Tracking issue: rust-lang/rust#129396
Improve doc of some methods that take ranges
Some methods that were taking some range in parameter were a bit inconsistent / unclear in the panic documentation.
Here is the recap:
- Replaced "start/end point" by "start/end bound" to be coherent with [`RangeBounds`](https://doc.rust-lang.org/stable/std/ops/trait.RangeBounds.html) naming (it's also easier to understand I think)
- Previously, it was written "_[...] or if the end point is greater than the length of [...]_", but this is not entirely true! Actually, you can have a start bound that is greater than the length, with an end bound that is unbounded and it will also panic. Therefore I think that "_[...] one of the range bound is bounded and greater than the length of [...]_" is better!
- `String` methods weren't mentionning that the method panics if `start_bound > end_bound` but it actually does! It uses `slice::range` which panics when `start > end`. (https://doc.rust-lang.org/stable/src/alloc/string.rs.html#1932-1934, https://doc.rust-lang.org/stable/src/core/slice/index.rs.html#835-837).
You can also test it with:
```rs
struct MyRange;
impl std::ops::RangeBounds<usize> for MyRange {
fn start_bound(&self) -> std::ops::Bound<&usize> {
std::ops::Bound::Included(&3usize)
}
fn end_bound(&self) -> std::ops::Bound<&usize> {
std::ops::Bound::Included(&1usize)
}
}
fn main() {
let mut s = String::from("I love Rust!");
s.drain(MyRange); // panics!
}
```
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.)
