Auto merge of #140127 - ChrisDenton:rollup-2kye32h, r=ChrisDenton

Rollup of 11 pull requests

Successful merges:

 - #134213 (Stabilize `naked_functions`)
 - #139711 (Hermit: Unify `std::env::args` with Unix)
 - #139795 (Clarify why SGX code specifies linkage/symbol names for certain statics)
 - #140036 (Advent of `tests/ui` (misc cleanups and improvements) [4/N])
 - #140047 (remove a couple clones)
 - #140052 (Fix error when an intra doc link is trying to resolve an empty associated item)
 - #140074 (rustdoc-json: Improve test for auto-trait impls)
 - #140076 (jsondocck: Require command is at start of line)
 - #140107 (rustc-dev-guide subtree update)
 - #140111 (cleanup redundant pattern instances)
 - #140118 ({B,C}Str: minor cleanup)

r? `@ghost`
`@rustbot` modify labels: rollup
This commit is contained in:
bors 2025-04-21 19:28:16 +00:00
commit 1803f55dec
2 changed files with 8 additions and 7 deletions

View File

@ -1 +1 @@
a7c39b68616668a45f0afd62849a1da7c8ad2516 b8005bff3248cfc6e327faf4fa631ac49bb49ba9

View File

@ -303,7 +303,7 @@ It should be preferred to using `error-pattern`, which is imprecise and non-exha
### `error-pattern` ### `error-pattern`
The `error-pattern` [directive](directives.md) can be used for runtime messages, which don't The `error-pattern` [directive](directives.md) can be used for runtime messages, which don't
have a specific span, or in exceptional cases for compile time messages. have a specific span, or in exceptional cases, for compile time messages.
Let's think about this test: Let's think about this test:
@ -316,7 +316,7 @@ fn main() {
} }
``` ```
We want to ensure this shows "index out of bounds" but we cannot use the `ERROR` We want to ensure this shows "index out of bounds", but we cannot use the `ERROR`
annotation since the runtime error doesn't have any span. Then it's time to use the annotation since the runtime error doesn't have any span. Then it's time to use the
`error-pattern` directive: `error-pattern` directive:
@ -333,18 +333,19 @@ fn main() {
Use of `error-pattern` is not recommended in general. Use of `error-pattern` is not recommended in general.
For strict testing of compile time output, try to use the line annotations `//~` as much as For strict testing of compile time output, try to use the line annotations `//~` as much as
possible, including `//~?` annotations for diagnostics without span. possible, including `//~?` annotations for diagnostics without spans.
If the compile time output is target dependent or too verbose, use directive If the compile time output is target dependent or too verbose, use directive
`//@ dont-require-annotations: <diagnostic-kind>` to make the line annotation checking `//@ dont-require-annotations: <diagnostic-kind>` to make the line annotation checking
non-exhaustive, some of the compiler messages can stay uncovered by annotations in this mode. non-exhaustive.
Some of the compiler messages can stay uncovered by annotations in this mode.
For checking runtime output `//@ check-run-results` may be preferable. For checking runtime output, `//@ check-run-results` may be preferable.
Only use `error-pattern` if none of the above works. Only use `error-pattern` if none of the above works.
Line annotations `//~` are still checked in tests using `error-pattern`. Line annotations `//~` are still checked in tests using `error-pattern`.
In exceptional cases use `//@ compile-flags: --error-format=human` to opt out of these checks. In exceptional cases, use `//@ compile-flags: --error-format=human` to opt out of these checks.
### Diagnostic kinds (error levels) ### Diagnostic kinds (error levels)