Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update docs about ui tests now using //@ headers #1885

Merged
merged 2 commits into from
Feb 16, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions src/tests/headers.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,8 @@ They must appear before the Rust source in the test.
They may also appear in Makefiles for [run-make tests](compiletest.md#run-make-tests).

They are normally put after the short comment that explains the point of this test.
Some test suites use `//@` to signal that a comment is a header, but most are still
just using plain comments.
Comment on lines +11 to +12
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an additional caveat:

// ignore-tidy and // ignore-tidy-* are specifically ignored by compiletest in "ui" test suite specifically.

For example, this test uses the `// compile-flags` command to specify a custom
flag to give to rustc when the test is compiled:

Expand Down
37 changes: 20 additions & 17 deletions src/tests/ui.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,10 @@ the source file.
See [Error annotations](#error-annotations) for more.

[Headers](headers.md) in the form of comments at the top of the file control
how the test is compiled and what the expected behavior is.
how the test is compiled and what the expected behavior is. Note that ui
tests require the use of `//@ header-name` instead of `// header-name` like
the other test suites do. The other test suites will be migrated to use the `//@`
syntax, too, but that is in progress.
compiler-errors marked this conversation as resolved.
Show resolved Hide resolved

Tests are expected to fail to compile, since most tests are testing compiler
errors.
Expand Down Expand Up @@ -126,7 +129,7 @@ more suitable for UI testing.
For example, it will anonymize line numbers in the output (line numbers
prefixing each source line are replaced with `LL`).
In extremely rare situations, this mode can be disabled with the header
command `// compile-flags: -Z ui-testing=no`.
command `//@ compile-flags: -Z ui-testing=no`.

Note: The line and column numbers for `-->` lines pointing to the test are
*not* normalized, and left as-is. This ensures that the compiler continues
Expand All @@ -139,9 +142,9 @@ Sometimes these built-in normalizations are not enough. In such cases, you
may provide custom normalization rules using the header commands, e.g.

```rust,ignore
// normalize-stdout-test: "foo" -> "bar"
// normalize-stderr-32bit: "fn\(\) \(32 bits\)" -> "fn\(\) \($$PTR bits\)"
// normalize-stderr-64bit: "fn\(\) \(64 bits\)" -> "fn\(\) \($$PTR bits\)"
//@ normalize-stdout-test: "foo" -> "bar"
//@ normalize-stderr-32bit: "fn\(\) \(32 bits\)" -> "fn\(\) \($$PTR bits\)"
//@ normalize-stderr-64bit: "fn\(\) \(64 bits\)" -> "fn\(\) \($$PTR bits\)"
```

This tells the test, on 32-bit platforms, whenever the compiler writes
Expand Down Expand Up @@ -291,7 +294,7 @@ We want to ensure this shows "index out of bounds" but we cannot use the
Then it's time to use the `error-pattern` header:

```rust,ignore
// error-pattern: index out of bounds
//@ error-pattern: index out of bounds
fn main() {
let a: *const [_] = &[1, 2, 3];
unsafe {
Expand Down Expand Up @@ -330,9 +333,9 @@ conditionally checked based on the current revision.
This is done by placing the revision cfg name in brackets like this:

```rust,ignore
// edition:2018
// revisions: mir thir
// [thir]compile-flags: -Z thir-unsafeck
//@ edition:2018
//@ revisions: mir thir
//@ [thir]compile-flags: -Z thir-unsafeck

async unsafe fn f() {}

Expand Down Expand Up @@ -363,20 +366,20 @@ and you can even run the resulting program.
Just add one of the following [header commands](headers.md):

* Pass headers:
* `// check-pass` — compilation should succeed but skip codegen
* `//@ check-pass` — compilation should succeed but skip codegen
(which is expensive and isn't supposed to fail in most cases).
* `// build-pass` — compilation and linking should succeed but do
* `//@ build-pass` — compilation and linking should succeed but do
not run the resulting binary.
* `// run-pass` — compilation should succeed and running the resulting
* `//@ run-pass` — compilation should succeed and running the resulting
binary should also succeed.
* Fail headers:
* `// check-fail` — compilation should fail (the codegen phase is skipped).
* `//@ check-fail` — compilation should fail (the codegen phase is skipped).
This is the default for UI tests.
* `// build-fail` — compilation should fail during the codegen phase.
* `//@ build-fail` — compilation should fail during the codegen phase.
This will run `rustc` twice, once to verify that it compiles successfully
without the codegen phase, then a second time the full compile should
fail.
* `// run-fail` — compilation should succeed, but running the resulting
* `//@ run-fail` — compilation should succeed, but running the resulting
binary should fail.

For `run-pass` and `run-fail` tests, by default the output of the program
Expand Down Expand Up @@ -466,8 +469,8 @@ and that the resulting changes compile correctly.
This can be done with the `run-rustfix` header:

```rust,ignore
// run-rustfix
// check-pass
//@ run-rustfix
//@ check-pass
#![crate_type = "lib"]

pub struct not_camel_case {}
Expand Down