This ensures the code-gen for these ABIs does not change silently.

Co-authored-by: Folkert <folkert@folkertdev.nl>

The latest versions of `memchr` experience LTO-related issues when
compiling for windows-gnu [1], so needs to be pinned. The issue is
present in the standard library.

`memchr` has been pinned in `rustc_ast`, but since the workspace was
recently split, this pin no longer has any effect on library crates.

Resolve this by adding `memchr` as an _unused_ dependency in `std`,
pinned to 2.5. Additionally, remove the pin in `rustc_ast` to allow
non-library crates to upgrade to the latest version.

Link: rust-lang#127890 [1]

Co-authored-by: David Tolnay <dtolnay@gmail.com>
Co-authored-by: nora <48135649+Noratrieb@users.noreply.github.com>

This changes the remaining span for the cast, because the new `Cast`
category has a higher priority (lower `Ord`) than the old `Coercion`
category, so we no longer report the region error for the "unsizing"
coercion from `*const Trait` to itself.

…leLapkin

improve compile errors for invalid ptr-to-ptr casts with trait objects

This is a follow-up to rust-lang#120248 to improve some of its error messages.

1. Make the borrowcheck error for "type annotation requires that x must outlive y" actually point at the type annotation, i.e. the type `T` in a `x as T` cast. This makes the error more consistent with other errors caused by type annotation in other places, such as
```text
error: lifetime may not live long enough
 --> src/lib.rs:4:12
  |
3 | fn bar(a: &i32) {
  |           - let's call the lifetime of this reference `'1`
4 |     let b: &'static i32 = a;
  |            ^^^^^^^^^^^^ type annotation requires that `'1` must outlive `'static`
```

2. Don't say "cast" when we actually mean "coercion" and give borrowcheck errors from actual casts (which is currently just the check added in rust-lang#120248) a higher priority than ones from coercions. This can improve the errors for ptr-to-ptr cast between trait objects because they are are lowered as an upcast "unsizing" coercion if possible (which may be the identity upcast) followed by the actual cast.

3. Bring back the old "casting X as Y is invalid" message for type mismatch in the principals and reword the "vtable kinds may not match" message to more accurately describe the pointer metadata and not refer to "vtables" if the metadata is unknown.

fixes rust-lang#130030

r? `@WaffleLapkin` but feel free to reassign

…ouxu

Improve assembly test for CMSE ABIs

Tracking issues: rust-lang#75835 rust-lang#81391

This ensures the code-gen for these ABIs does not change silently. There is a small chance that this code-gen might change, however even GCC (https://godbolt.org/z/16arxab5x and https://godbolt.org/z/16arxab5x) generates almost the same assembly for these ABIs. I hope the notes in the comments should help fix the tests if it ever breaks.

Separate collection of crate-local inherent impls from error tracking

rust-lang#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until rust-lang#121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.

Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in rust-lang#127798.

This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.

This fixes rust-lang#127798.

…eb,Mark-Simulacrum

Pin memchr to 2.5.0 in the library rather than rustc_ast

The latest versions of `memchr` experience LTO-related issues when compiling for windows-gnu [1], so needs to be pinned. The issue is present in the standard library.

`memchr` has been pinned in `rustc_ast`, but since the workspace was recently split, this pin no longer has any effect on library crates.

Resolve this by adding `memchr` as an _unused_ dependency in `std`, pinned to 2.5. Additionally, remove the pin in `rustc_ast` to allow non-library crates to upgrade to the latest version.

Link: rust-lang#127890 [1]

try-job: x86_64-mingw
try-job: x86_64-msvc

add InProgress ErrorKind gated behind io_error_inprogress feature

Follow up on rust-lang/libs-team#92 (comment)

…r=matthiaskrgr

Mention `COMPILETEST_VERBOSE_CRASHES` on crash test failure

Fixes rust-lang#130776.

r? `@matthiaskrgr` (or compiler/bootstrap)

rustdoc: inherit parent's stability where applicable

It is currently not possible for a re-export to have a different stability (rust-lang#30827). Therefore the standard library uses a hack when moving items like `std::error::Error` or `std::net::IpAddr` into `core` by marking the containing module (`core::error` / `core::net`) as unstable or stable in a later version than the items the module contains.

Previously, rustdoc would always show the *stability as declared* for an item rather than the *stability as publicly reachable* (i.e. the features required to actually access the item), which could be confusing when viewing the docs. This PR changes it so that we show the stability of the first unstable parent or the most recently stabilized parent instead, to hopefully make things less confusing.

fixes rust-lang#130765

screenshots:
![error in std](https://github.com/user-attachments/assets/2ab9bdb9-ed81-4e45-a832-ac7d3ba1be3f) ![error in core](https://github.com/user-attachments/assets/46f46182-5642-4ac5-b92e-0b99a8e2496d)