Most of these are meant to test possible future improvements, but since
they cover cases the existing test suite didn't, I figure including them
now may be helpful.
This aligns the main error message a bit more with the phrasing in the
Edition Guide and provides a bit more information on the labels to
(hopefully!) aid in understanding.
Explain why we retroactively change a static initializer to have a different type
I keep getting confused about it and in turn confused `@GuillaumeGomez` while trying to explain it badly
Shorten error message for callable with wrong return type
```
error: expected `{closure@...}` to return `Ret`, but it returns `Other`
```
instead of
```
error: expected `{closure@...}` to be a closure that returns `Ret`, but it returns `Other`
```
Fix malformed error annotations in a UI test
The compiletest DSL still features a historical remnant from the time when its directives were merely prefixed with `//` instead of `//`@`` when unknown directive names weren't rejected since they could just as well be part of prose:
As an "optimization", it stops looking for directives once it stumbles upon a line which starts with either `fn` or `mod`. This allowed a malformed error annotation of the form `//`@[…]~^^^`` to go undetected & unexercised (as it's placed below `fn main() {`).
Obviously a character other than ``@`` would've mangled the error annotation, too (but it might've caught the reviewer's eye). I specifically found this file because I ran `rg '^(fn|mod)[\s\S]*?//`@'` tests/ui --multiline -trust` to check how footgun-y that "special feature" of compiletest is.
CompileTest: Add Directives to Ignore `arm-unknown-*` Targets
In #134626, I want to ignore `arm-unknown-*` targets because the LLVM IR for those looks very different compared to other targets: https://rust.godbolt.org/z/ssYMhdv4x.
I can use `ignore-arm` but, I think, it would exclude large number of Apple devices.
So this PR adds a few directives to ignore `arm-unknown-*` targets specifically.
Test validity of pattern types
r? `@RalfJung`
pulled out of #136006 so we don't have to rely on libcore types excercising this code path
There's nothing to fix. `rustc_layout_scalar_valid_range_start` structs just failed their validation on their value instead of their fields' value, causing a diff where moving to pattern types adds an additional `.0` field access to the validation error
This is necessary to unblock rust-lang/rust#122408. The documentation for these is available [here](https://developer.apple.com/documentation/os/os_sync_wait_on_address?language=objc).
Because the futex wait operations (`os_sync_wait_on_address` et al.) return the number of remaining waiters after returning, this required some changes to the common futex infrastructure, which I've changed to take a callback instead of precalculating the return values.
rustc_allowed_through_unstable_modules: require deprecation message
This changes the `#[rustc_allowed_through_unstable_modules]` attribute so that a deprecation message (ideally directing people towards the stable path) is required.
