diff --git a/src/compiletest.md b/src/compiletest.md index 3cfb943b07..1b424e1a24 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -16,8 +16,8 @@ expect, and more. If you are unfamiliar with the compiler testing framework, see [this chapter](./tests/intro.html) for additional background. The tests themselves are typically (but not always) organized into -"suites" – for example, `run-pass`, a folder representing tests that should -succeed, `run-fail`, a folder holding tests that should compile successfully, +"suites" – for example, `run-fail`, +a folder holding tests that should compile successfully, but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various suites are defined in [src/tools/compiletest/src/common.rs][common] in the `pub struct Config` diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index c3968b591f..0a746177bb 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -483,7 +483,7 @@ in other sections: - Running tests (see the [section on running tests](./tests/running.html) for more details): - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite + - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in the `const-generics/` subdirectory of the `ui` test suite - `./x.py test --stage 1 src/test/ui/const-generics/const-types.rs` - runs diff --git a/src/tests/adding.md b/src/tests/adding.md index d88b7cf574..a660d26b56 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -43,14 +43,14 @@ rough heuristics: We have not traditionally had a lot of structure in the names of tests. Moreover, for a long time, the rustc test runner did not support subdirectories (it now does), so test suites like -[`src/test/run-pass`] have a huge mess of files in them. This is not +[`src/test/ui`] have a huge mess of files in them. This is not considered an ideal setup. -[`src/test/run-pass`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass/ +[`src/test/ui`]: https://github.com/rust-lang/rust/tree/master/src/test/ui/ For regression tests – basically, some random snippet of code that came in from the internet – we often just name the test after the -issue. For example, `src/test/run-pass/issue-12345.rs`. If possible, +issue. For example, `src/test/ui/issue-12345.rs`. If possible, though, it is better if you can put the test into a directory that helps identify what piece of code is being tested here (e.g., `borrowck/issue-12345.rs` is much better), or perhaps give it a more @@ -58,11 +58,8 @@ meaningful name. Still, **do include the issue number somewhere**. When writing a new feature, **create a subdirectory to store your tests**. For example, if you are implementing RFC 1234 ("Widgets"), -then it might make sense to put the tests in directories like: - -- `src/test/ui/rfc1234-widgets/` -- `src/test/run-pass/rfc1234-widgets/` -- etc +then it might make sense to put the tests in a directory like +`src/test/ui/rfc1234-widgets/`. In other cases, there may already be a suitable directory. (The proper directory structure to use is actually an area of active debate.) @@ -216,7 +213,7 @@ The error levels that you can have are: ## Revisions Certain classes of tests support "revisions" (as of the time of this -writing, this includes run-pass, compile-fail, run-fail, and +writing, this includes compile-fail, run-fail, and incremental, though incremental tests are somewhat different). Revisions allow a single test file to be used for multiple tests. This is done by adding a special header at the top of the file: diff --git a/src/tests/running.md b/src/tests/running.md index 01d308f0b9..ef3227f9ab 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -34,10 +34,10 @@ test" that can be used after modifying rustc to see if things are generally working correctly would be the following: ```bash -> ./x.py test --stage 1 src/test/{ui,compile-fail,run-pass} +> ./x.py test --stage 1 src/test/{ui,compile-fail} ``` -This will run the `ui`, `compile-fail`, and `run-pass` test suites, +This will run the `ui` and `compile-fail` test suites, and only with the stage 1 build. Of course, the choice of test suites is somewhat arbitrary, and may not suit the task you are doing. For example, if you are hacking on debuginfo, you may be better off with @@ -114,10 +114,10 @@ Pass UI tests now have three modes, `check-pass`, `build-pass` and `run-pass`. When `--pass $mode` is passed, these tests will be forced to run under the given `$mode` unless the directive `// ignore-pass` exists in the test file. For example, you can run all the tests in -`src/test/run-pass` as `check-pass`: +`src/test/ui` as `check-pass`: ```bash -> ./x.py test --stage 1 src/test/run-pass --pass check +> ./x.py test --stage 1 src/test/ui --pass check ``` By passing `--pass $mode`, you can reduce the testing time. For each