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
