Tidy up `dump-ice-to-disk` and make assertion failures dump ICE messages
For the future traveler: **if you did a `git blame` and found this PR that last modified `dump-ice-to-disk` because the test failed in a completely unrelated PR, then I'm afraid our ICE dump may have regressed or somehow behaves differently on `i686-mingw`.**
A bit of clean up to the `dump-ice-to-disk` test.
- Fixes/updates the top-level comment.
- Add a FIXME pointing to #128911 for flakiness.
- Instead of trying to manually cleanup `rustc-ice*.txt` dumps, run each test instance in a separate temp directory.
- Explicitly make `RUSTC_ICE` unavailable in one of the `-Zmetrics-dir` test case to not have interference from environment.
- Make assertion failures (on ICE dump line count mismatch) extremely verbose to help debug why this test is flakey in CI (#128911).
Contains a fix by `@saethlin` in #128909, should wait until that is merged then rebase on top.
try-job: aarch64-gnu
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: i686-mingw
try-job: test-various
rm `import.used`
By the way, `import_used_map` will only be used during `build_reduced_graph` and `finalize`, so it can be split from `Resolver` in the future.
r? ``@petrochenkov``
Use more slice patterns inside the compiler
Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.
r? ghost
Promote aarch64-apple-darwin to Tier 1
This promotes aarch64-apple-darwin to Tier 1 status as per rust-lang/rfcs#3671 and tracking issue #73908. Not sure what else is necessary for this to impement the aforementioned RFC, however I figured I'd try. I did read in previous issues and PRs that the necessary infrastructure was already in place for the aarch64-apple-darwin target, and the RFC mentions the same. So this should be all thats necessary in order for the target to be promoted.
This is a recreation of my previous PR because I accidentally did an incorrect git rebase which caused unnecessary changes to various commit SHAs. So this PR is a recreation of my previous PR without said stumble. My bad.
Preliminary cleanup of `WitnessPat` hoisting/printing
Follow-up to #128430.
The eventual goal is to remove `print::Pat` entirely, but in the course of working towards that I made so many small improvements that it seems wise to let those be reviewed/merged on their own first.
Best reviewed commit-by-commit, most of which should be pretty simple and straightforward.
r? ``@Nadrieril``
core: optimise Debug impl for ascii::Char
Rather than writing character at a time, optimise Debug implementation
for core::ascii::Char such that it writes the entire representation
with a single write_str call.
With that, add tests for Display and Debug.
Issue: https://github.com/rust-lang/rust/issues/110998
Fix `ElaborateBoxDerefs` on debug varinfo
Slightly simplifies the `ElaborateBoxDerefs` pass to fix cases where it was applying the wrong projections to debug var infos containing places that deref boxes.
From what I can tell[^1], we don't actually have any tests (or code anywhere, really) that exercise `debug x => *(...: Box<T>)`, and it's very difficult to trigger this in surface Rust, so I wrote a custom MIR test.
What happens is that the pass was turning `*(SOME_PLACE: Box<T>)` into `*(*((((SOME_PLACE).0: Unique<T>).0: NonNull<T>).0: *const T))` in debug var infos. In particular, notice the *double deref*, which was wrong.
This is the root cause of #128554, so this PR fixes#128554 as well. The reason that async closures was affected is because of the way that we compute the [`ByMove` body](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_transform/src/coroutine/by_move_body.rs), which resulted in `*(...: Box<T>)` in debug var info. But this really has nothing to do with async closures.
[^1]: Validated by literally replacing the `if elem == PlaceElem::Deref && base_ty.is_box() { ... }` innards with a `panic!()`, which compiled all of stage2 without panicking.
[rustdoc] Stop showing impl items for negative impls
Fixes https://github.com/rust-lang/rust/issues/128799.
As discussed with `@fmease,` they have a broader patch in progress, so this (small) PR will at least allow for them to have a regression test. :)
r? `@fmease`
Differentiate between methods and associated functions in diagnostics
Accurately refer to assoc fn without receiver as assoc fn instead of methods. Add `AssocItem::descr` method to centralize where we call methods and associated functions.
