bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity

Rollup merge of #140107 - tshepang:rdg-push, r=jieyouxu

Browse source 
rustc-dev-guide subtree update

r? ``@ghost``
This commit is contained in:
Chris Denton 2025-04-21 18:53:20 +00:00 • committed by GitHub
commit ef167557b6
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 8 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

2
src/doc/rustc-dev-guide/rust-version
View file

@ -1 +1 @@
a7c39b68616668a45f0afd62849a1da7c8ad2516
b8005bff3248cfc6e327faf4fa631ac49bb49ba9

13
src/doc/rustc-dev-guide/src/tests/ui.md
View file

@ -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)