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:
commit
1803f55dec
|
|
@ -1 +1 @@
|
|||
a7c39b68616668a45f0afd62849a1da7c8ad2516
|
||||
b8005bff3248cfc6e327faf4fa631ac49bb49ba9
|
||||
|
|
|
|||
|
|
@ -303,7 +303,7 @@ It should be preferred to using `error-pattern`, which is imprecise and non-exha
|
|||
### `error-pattern`
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -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
|
||||
`error-pattern` directive:
|
||||
|
||||
|
|
@ -333,18 +333,19 @@ fn main() {
|
|||
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
|
||||
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
|
||||
`//@ 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.
|
||||
|
||||
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)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue