Introduce "wrapper" helpers to rustdoc
Add a few traits for streamlining places where we need to wrap certain `fmt::Display`s in stuff like parentheses or brackets.
Hopefully this makes the actual display logic slightly easier to read.
First two commits are small, unrelated cleanups.
I'll probably add some doc comments to the stuff in `display.rs`, maybe also play around with the API, but wanted to get feedback on this idea first.
emit attribute for readonly non-pure inline assembly
fixes https://github.com/rust-lang/rust/issues/146761
Provide a better `MemoryEffects` to LLVM when an inline assembly block specifies `readonly` but not `pure`. That means that the assembly block may not perform any writes, but that there still may be side effects from its instructions.
I haven't been able to find a case yet where this actually matters, though. So the test checks that the right attribute is applied, but the generated assembly is equivalent to not specifying `readonly` at all.
r? ````@nikic````
cc ````@Amanieu````
std_detect on Darwin AArch64: update features
Synchronizes the list (and re-sorts it alphabetically by `FEAT` name) with the initial release version of macOS Tahoe.
Implement a simple diagnostic system for tidy
In https://github.com/rust-lang/rust/pull/146316 and https://github.com/rust-lang/rust/pull/146580, contributors independently wanted to reduce the verbose output of tidy. But before, the output was quite ad-hoc, so it was not easy to control it.
In this PR, I implemented a simple diagnostic system for tidy, which allows us to:
1) Only print certain information in verbose mode (`-v`)
2) Associate each (error) output to a specific check, so that it is easier to find out what exactly has failed and which check you might want to examine (not fully done, there are some random `println`s left, but most output should be scoped to a specific check)
3) Print output with colors, based on the message level (message, warning, error)
4) Show the start/end execution of each check in verbose mode, for better progress indication
Failure output:
<img width="1134" height="157" alt="image" src="https://github.com/user-attachments/assets/578a9302-e1c2-47e5-9370-a3556c49d9fc" />
Success output:
<img width="388" height="113" alt="image" src="https://github.com/user-attachments/assets/cf27faf8-3d8b-49e3-88d0-fac27a9c36a8" />
Verbose output (shortened):
<img width="380" height="158" alt="image" src="https://github.com/user-attachments/assets/ce7102b8-c2f3-42a8-a2ec-ca30389be91e" />
CC `@nnethercote` `@RalfJung` `@GuillaumeGomez`
The first two commits and the last commit are interesting, the rest is just mechanical port of the code from `bad: &mut bool` to `DiagCtx` and `RunningCheck`.
The `extra_checks` check could be further split, but I'd leave that for another PR.
r? `@jieyouxu`
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`
