compiletest: Support matching on diagnostics without a span

This commit is contained in:
Vadim Petrochenkov 2025-03-23 15:50:51 +03:00
parent 8194ffca04
commit 2e81955d9c
1 changed files with 22 additions and 4 deletions

View File

@ -202,6 +202,9 @@ several ways to match the message with the line (see the examples below):
* `~|`: Associates the error level and message with the *same* line as the
*previous comment*. This is more convenient than using multiple carets when
there are multiple messages associated with the same line.
* `~?`: Used to match error levels and messages with errors not having line
information. These can be placed on any line in the test file, but are
conventionally placed at the end.
Example:
@ -270,10 +273,23 @@ fn main() {
//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023]
```
#### Error without line information
Use `//~?` to match an error without line information.
`//~?` is precise and will not match errors if their line information is available.
It should be preferred to using `error-pattern`, which is imprecise and non-exhaustive.
```rust,ignore
//@ compile-flags: --print yyyy
//~? ERROR unknown print request: `yyyy`
```
### `error-pattern`
The `error-pattern` [directive](directives.md) can be used for messages that don't
have a specific span.
The `error-pattern` [directive](directives.md) can be used for runtime messages, which don't
have a specific span, or for compile time messages if imprecise matching is required due to
multi-line platform specific diagnostics.
Let's think about this test:
@ -300,7 +316,9 @@ fn main() {
}
```
But for strict testing, try to use the `ERROR` annotation as much as possible.
But for strict testing, try to use the `ERROR` annotation as much as possible,
including `//~?` annotations for diagnostics without span.
For compile time diagnostics `error-pattern` should very rarely be necessary.
### Error levels
@ -353,7 +371,7 @@ would be a `.mir.stderr` and `.thir.stderr` file with the different outputs of
the different revisions.
> Note: cfg revisions also work inside the source code with `#[cfg]` attributes.
>
>
> By convention, the `FALSE` cfg is used to have an always-false config.
## Controlling pass/fail expectations