@@ -136,6 +136,9 @@ Some examples of `X` in `ignore-X`:
136
136
* Stage: ` stage0 ` , ` stage1 ` , ` stage2 ` .
137
137
* When cross compiling: ` cross-compile `
138
138
* When remote testing is used: ` remote `
139
+ * When debug-assertions are enabled: ` debug `
140
+ * When particular debuggers are being tested: ` cdb ` , ` gdb ` , ` lldb `
141
+ * Specific compare modes: ` compare-mode-nll ` , ` compare-mode-polonius `
139
142
140
143
### Other Header Commands
141
144
@@ -204,8 +207,8 @@ Error annotations specify the errors that the compiler is expected to
204
207
emit. They are "attached" to the line in source where the error is
205
208
located. Error annotations are considered during tidy lints of line
206
209
length and should be formatted according to tidy requirements. You may
207
- use an error message prefix sub-string if necessary to meet line length
208
- requirements. Make sure that the text is long enough for the error
210
+ use an error message prefix sub-string if necessary to meet line length
211
+ requirements. Make sure that the text is long enough for the error
209
212
message to be self-documenting.
210
213
211
214
The error annotation definition and source line definition association
@@ -216,7 +219,7 @@ is defined with the following set of idioms:
216
219
* ` ~| ` : Associates the following error level and message with the same
217
220
line as the previous comment
218
221
* ` ~^ ` : Associates the following error level and message with the
219
- previous error annotation line. Each caret (` ^ ` ) that you add adds
222
+ previous error annotation line. Each caret (` ^ ` ) that you add adds
220
223
a line to this, so ` ~^^^ ` is three lines above the error annotation
221
224
line.
222
225
@@ -242,8 +245,8 @@ fn main() {
242
245
#### Positioned below error line
243
246
244
247
Use the ` //~^ ` idiom with number of carets in the string to indicate the
245
- number of lines above. In the example below, the error line is four
246
- lines above the error annotation line so four carets are included in
248
+ number of lines above. In the example below, the error line is four
249
+ lines above the error annotation line so four carets are included in
247
250
the annotation.
248
251
249
252
``` rust,ignore
@@ -259,7 +262,7 @@ fn main() {
259
262
260
263
#### Use same error line as defined on error annotation line above
261
264
262
- Use the ` //~| ` idiom to define the same error line as
265
+ Use the ` //~| ` idiom to define the same error line as
263
266
the error annotation line above:
264
267
265
268
``` rust,ignore
@@ -360,12 +363,43 @@ you can even run the resulting program. Just add one of the following
360
363
361
364
### Normalization
362
365
363
- The normalization applied is aimed at eliminating output difference
364
- between platforms, mainly about filenames:
365
-
366
- - the test directory is replaced with ` $DIR `
367
- - all backslashes (` \ ` ) are converted to forward slashes (` / ` ) (for Windows)
368
- - all CR LF newlines are converted to LF
366
+ The compiler output is normalized to eliminate output difference between
367
+ platforms, mainly about filenames.
368
+
369
+ The following strings replace their corresponding values:
370
+
371
+ - ` $DIR ` : The directory where the test is defined.
372
+ - Example: ` /path/to/rust/src/test/ui/error-codes `
373
+ - ` $SRC_DIR ` : The root source directory.
374
+ - Example: ` /path/to/rust/src `
375
+ - ` $TEST_BUILD_DIR ` : The base directory where the test's output goes.
376
+ - Example: ` /path/to/rust/build/x86_64-unknown-linux-gnu/test/ui `
377
+
378
+ Additionally, the following changes are made:
379
+
380
+ - Line and column numbers for paths in ` $SRC_DIR ` are replaced with ` LL:CC ` .
381
+ For example, ` /path/to/rust/src/libcore/clone.rs:122:8 ` is replaced with
382
+ ` $SRC_DIR/libcore/clone.rs:LL:COL ` .
383
+
384
+ Note: The line and column numbers for ` --> ` lines pointing to the test are
385
+ * not* normalized, and left as-is. This ensures that the compiler continues
386
+ to point to the correct ___location, and keeps the stderr files readable.
387
+ Ideally all line/column information would be retained, but small changes to
388
+ the source causes large diffs, and more frequent merge conflicts and test
389
+ errors. See also ` -Z ui-testing ` below which applies additional line number
390
+ normalization.
391
+ - ` \t ` is replaced with an actual tab character.
392
+ - Error line annotations like ` // ~ERROR some message ` are removed.
393
+ - Backslashes (` \ ` ) are converted to forward slashes (` / ` ) within paths (using
394
+ a heuristic). This helps normalize differences with Windows-style paths.
395
+ - CRLF newlines are converted to LF.
396
+
397
+ Additionally, the compiler is run with the ` -Z ui-testing ` flag which causes
398
+ the compiler itself to apply some changes to the diagnostic output to make it
399
+ more suitable for UI testing. For example, it will anonymize line numbers in
400
+ the output (line numbers prefixing each source line are replaced with ` LL ` ).
401
+ In extremely rare situations, this mode can be disabled with the header
402
+ command ` // compile-flags: -Z ui-testing=no ` .
369
403
370
404
Sometimes these built-in normalizations are not enough. In such cases, you
371
405
may provide custom normalization rules using the header commands, e.g.
@@ -399,6 +433,6 @@ concrete usage example.
399
433
[ `main.stderr` ] : https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr
400
434
401
435
Besides ` normalize-stderr-32bit ` and ` -64bit ` , one may use any target
402
- information or stage supported by ` ignore-X ` here as well (e.g.
436
+ information or stage supported by [ ` ignore-X ` ] ( #ignoring-tests ) here as well (e.g.
403
437
` normalize-stderr-windows ` or simply ` normalize-stderr-test ` for unconditional
404
438
replacement).
0 commit comments