Make mips64el-unknown-linux-muslabi64 link dynamically
I missed this target when I changed all the other tier 3 targets in https://github.com/rust-lang/rust/pull/144410. Only realized that this one was still statically linked when I looked at the list of targets in the test later (https://github.com/rust-lang/rust/pull/146588).
since those two PRs were reviewed by you:
r? ````@jieyouxu````
Add self-profile events for target-machine creation
These code paths are surprisingly hot in the `large-workspace` benchmark (e.g. see perf changes from rust-lang/rust#146700), suggesting room for more improvement. It would be handy to see some detailed timings and execution counts.
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.
I missed this target when I changed all the other tier 3 targets. Only
realized that this one was still statically linked when I looked at the
list of targets in the test later.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
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
