Merge from rustc
This commit is contained in:
commit
e7d2f0855d
|
|
@ -202,6 +202,12 @@ 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
|
* `~|`: Associates the error level and message with the *same* line as the
|
||||||
*previous comment*. This is more convenient than using multiple carets when
|
*previous comment*. This is more convenient than using multiple carets when
|
||||||
there are multiple messages associated with the same line.
|
there are multiple messages associated with the same line.
|
||||||
|
* `~v`: Associates the error level and message with the *next* error
|
||||||
|
annotation line. Each symbol (`v`) that you add adds a line to this, so `~vvv`
|
||||||
|
is three lines below the error annotation 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:
|
Example:
|
||||||
|
|
||||||
|
|
@ -270,10 +276,35 @@ fn main() {
|
||||||
//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023]
|
//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023]
|
||||||
```
|
```
|
||||||
|
|
||||||
|
#### Positioned above error line
|
||||||
|
|
||||||
|
Use the `//~v` idiom with number of v's in the string to indicate the number
|
||||||
|
of lines below. This is typically used in lexer or parser tests matching on errors like unclosed
|
||||||
|
delimiter or unclosed literal happening at the end of file.
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
// ignore-tidy-trailing-newlines
|
||||||
|
//~v ERROR this file contains an unclosed delimiter
|
||||||
|
fn main((ؼ
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 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`
|
### `error-pattern`
|
||||||
|
|
||||||
The `error-pattern` [directive](directives.md) can be used for messages that don't
|
The `error-pattern` [directive](directives.md) can be used for runtime messages, which don't
|
||||||
have a specific span.
|
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:
|
Let's think about this test:
|
||||||
|
|
||||||
|
|
@ -300,7 +331,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
|
### Error levels
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue