Skip to content

Commit e7d2f08

Browse files
committed
Merge from rustc
2 parents 80da592 + 9720c5c commit e7d2f08

File tree

1 file changed

+37
-4
lines changed

1 file changed

+37
-4
lines changed

src/tests/ui.md

Lines changed: 37 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -202,6 +202,12 @@ several ways to match the message with the line (see the examples below):
202202
* `~|`: Associates the error level and message with the *same* line as the
203203
*previous comment*. This is more convenient than using multiple carets when
204204
there are multiple messages associated with the same line.
205+
* `~v`: Associates the error level and message with the *next* error
206+
annotation line. Each symbol (`v`) that you add adds a line to this, so `~vvv`
207+
is three lines below the error annotation line.
208+
* `~?`: Used to match error levels and messages with errors not having line
209+
information. These can be placed on any line in the test file, but are
210+
conventionally placed at the end.
205211

206212
Example:
207213

@@ -270,10 +276,35 @@ fn main() {
270276
//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023]
271277
```
272278

279+
#### Positioned above error line
280+
281+
Use the `//~v` idiom with number of v's in the string to indicate the number
282+
of lines below. This is typically used in lexer or parser tests matching on errors like unclosed
283+
delimiter or unclosed literal happening at the end of file.
284+
285+
```rust,ignore
286+
// ignore-tidy-trailing-newlines
287+
//~v ERROR this file contains an unclosed delimiter
288+
fn main((ؼ
289+
```
290+
291+
#### Error without line information
292+
293+
Use `//~?` to match an error without line information.
294+
`//~?` is precise and will not match errors if their line information is available.
295+
It should be preferred to using `error-pattern`, which is imprecise and non-exhaustive.
296+
297+
```rust,ignore
298+
//@ compile-flags: --print yyyy
299+
300+
//~? ERROR unknown print request: `yyyy`
301+
```
302+
273303
### `error-pattern`
274304

275-
The `error-pattern` [directive](directives.md) can be used for messages that don't
276-
have a specific span.
305+
The `error-pattern` [directive](directives.md) can be used for runtime messages, which don't
306+
have a specific span, or for compile time messages if imprecise matching is required due to
307+
multi-line platform specific diagnostics.
277308

278309
Let's think about this test:
279310

@@ -300,7 +331,9 @@ fn main() {
300331
}
301332
```
302333

303-
But for strict testing, try to use the `ERROR` annotation as much as possible.
334+
But for strict testing, try to use the `ERROR` annotation as much as possible,
335+
including `//~?` annotations for diagnostics without span.
336+
For compile time diagnostics `error-pattern` should very rarely be necessary.
304337

305338
### Error levels
306339

@@ -353,7 +386,7 @@ would be a `.mir.stderr` and `.thir.stderr` file with the different outputs of
353386
the different revisions.
354387

355388
> Note: cfg revisions also work inside the source code with `#[cfg]` attributes.
356-
>
389+
>
357390
> By convention, the `FALSE` cfg is used to have an always-false config.
358391
359392
## Controlling pass/fail expectations

0 commit comments

Comments
 (0)