Change `src/test` to `tests` (#1547)
This commit is contained in:
Albert Larsan
GitHub
parent
03902fe1f0
commit
d4ec98736e
|
|
@ -3,7 +3,7 @@
|
|||
What's a project without a sense of humor? And frankly some of these are
|
||||
enlightening?
|
||||
|
||||
- [Weird exprs test](https://github.com/rust-lang/rust/blob/master/src/test/ui/weird-exprs.rs)
|
||||
- [Weird exprs test](https://github.com/rust-lang/rust/blob/master/tests/ui/weird-exprs.rs)
|
||||
- [Ferris Rap](http://fitzgeraldnick.com/2018/12/13/rust-raps.html)
|
||||
- [The Genesis of Generic Germination](https://github.com/rust-lang/rust/pull/53645#issue-210543221)
|
||||
- [The Bastion of the Turbofish test](https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/test/ui/bastion-of-the-turbofish.rs)
|
||||
|
|
|
|||
|
|
@ -361,9 +361,9 @@ can't know ahead of time whether a function will require a frame/base pointer.
|
|||
|
||||
Various tests for inline assembly are available:
|
||||
|
||||
- `src/test/assembly/asm`
|
||||
- `src/test/ui/asm`
|
||||
- `src/test/codegen/asm-*`
|
||||
- `tests/assembly/asm`
|
||||
- `tests/ui/asm`
|
||||
- `tests/codegen/asm-*`
|
||||
|
||||
Every architecture supported by inline assembly must have exhaustive tests in
|
||||
`src/test/assembly/asm` which test all combinations of register classes and types.
|
||||
`tests/assembly/asm` which test all combinations of register classes and types.
|
||||
|
|
|
|||
|
|
@ -193,14 +193,14 @@ Build artifacts include, but are not limited to:
|
|||
without building `rustc` from source ('build with stage 0, then test the
|
||||
artifacts'). If you're working on the standard library, this is normally the
|
||||
test command you want.
|
||||
- `./x.py test src/test/ui` means to build the stage 1 compiler and run
|
||||
- `./x.py test tests/ui` means to build the stage 1 compiler and run
|
||||
`compiletest` on it. If you're working on the compiler, this is normally the
|
||||
test command you want.
|
||||
|
||||
#### Examples of what *not* to do
|
||||
|
||||
- `./x.py test --stage 0 src/test/ui` is not useful: it runs tests on the
|
||||
_beta_ compiler and doesn't build `rustc` from source. Use `test src/test/ui`
|
||||
- `./x.py test --stage 0 tests/ui` is not useful: it runs tests on the
|
||||
_beta_ compiler and doesn't build `rustc` from source. Use `test tests/ui`
|
||||
instead, which builds stage 1 from source.
|
||||
- `./x.py test --stage 0 compiler/rustc` builds the compiler but runs no tests:
|
||||
it's running `cargo test -p rustc`, but cargo doesn't understand Rust's
|
||||
|
|
@ -386,7 +386,7 @@ recompiling all dependencies.
|
|||
`CARGOFLAGS` will pass arguments to cargo itself (e.g. `--timings`). `CARGOFLAGS_BOOTSTRAP` and
|
||||
`CARGOFLAGS_NOT_BOOTSTRAP` work analogously to `RUSTFLAGS_BOOTSTRAP`.
|
||||
|
||||
`--test-args` will pass arguments through to the test runner. For `src/test/ui`, this is
|
||||
`--test-args` will pass arguments through to the test runner. For `tests/ui`, this is
|
||||
compiletest; for unit tests and doctests this is the `libtest` runner. Most test runner accept
|
||||
`--help`, which you can use to find out the options accepted by the runner.
|
||||
|
||||
|
|
|
|||
|
|
@ -223,10 +223,10 @@ in other sections:
|
|||
- Running tests (see the [section on running tests](../tests/running.html) for
|
||||
more details):
|
||||
- `./x.py test library/std` – runs the unit tests and integration tests from `std`
|
||||
- `./x.py test src/test/ui` – runs the `ui` test suite
|
||||
- `./x.py test src/test/ui/const-generics` - runs all the tests in
|
||||
- `./x.py test tests/ui` – runs the `ui` test suite
|
||||
- `./x.py test tests/ui/const-generics` - runs all the tests in
|
||||
the `const-generics/` subdirectory of the `ui` test suite
|
||||
- `./x.py test src/test/ui/const-generics/const-types.rs` - runs
|
||||
- `./x.py test tests/ui/const-generics/const-types.rs` - runs
|
||||
the single test `const-types.rs` from the `ui` test suite
|
||||
|
||||
### Cleaning out build directories
|
||||
|
|
|
|||
|
|
@ -172,8 +172,8 @@ rebuild. That ought to fix the problem.
|
|||
|
||||
You can also use `--keep-stage 1` when running tests. Something like this:
|
||||
|
||||
- Initial test run: `./x.py test src/test/ui`
|
||||
- Subsequent test run: `./x.py test src/test/ui --keep-stage 1`
|
||||
- Initial test run: `./x.py test tests/ui`
|
||||
- Subsequent test run: `./x.py test tests/ui --keep-stage 1`
|
||||
|
||||
## Fine-tuning optimizations
|
||||
|
||||
|
|
|
|||
|
|
@ -147,14 +147,14 @@ You can read more about rustdoc in [this chapter][rustdocch].
|
|||
|
||||
## Tests
|
||||
|
||||
The test suite for all of the above is in [`src/test/`]. You can read more
|
||||
The test suite for all of the above is in [`tests/`]. You can read more
|
||||
about the test suite [in this chapter][testsch].
|
||||
|
||||
The test harness itself is in [`src/tools/compiletest`].
|
||||
|
||||
[testsch]: ./tests/intro.md
|
||||
|
||||
[`src/test/`]: https://github.com/rust-lang/rust/tree/master/src/test
|
||||
[`tests/`]: https://github.com/rust-lang/rust/tree/master/tests
|
||||
[`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest
|
||||
|
||||
## Build System
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ There are various ways to write tests against the dependency graph.
|
|||
The simplest mechanisms are the `#[rustc_if_this_changed]` and
|
||||
`#[rustc_then_this_would_need]` annotations. These are used in ui tests
|
||||
to test whether the expected set of paths exist in the dependency graph.
|
||||
As an example, see `src/test/ui/dep-graph/dep-graph-caller-callee.rs`.
|
||||
As an example, see `tests/ui/dep-graph/dep-graph-caller-callee.rs`.
|
||||
|
||||
The idea is that you can annotate a test like:
|
||||
|
||||
|
|
|
|||
|
|
@ -297,15 +297,15 @@ Expected results for both the `mir-opt` tests and the `coverage*` tests under
|
|||
|
||||
```shell
|
||||
$ ./x.py test mir-opt --bless
|
||||
$ ./x.py test src/test/run-make-fulldeps/coverage --bless
|
||||
$ ./x.py test tests/run-make-fulldeps/coverage --bless
|
||||
```
|
||||
|
||||
[mir-opt-test]: https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/instrument_coverage.rs
|
||||
[coverage-test-samples]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage
|
||||
[`coverage-reports`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage-reports
|
||||
[`coverage-spanview`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage-spanview
|
||||
[mir-opt-test]: https://github.com/rust-lang/rust/blob/master/tests/mir-opt/instrument_coverage.rs
|
||||
[coverage-test-samples]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage
|
||||
[`coverage-reports`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-reports
|
||||
[`coverage-spanview`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-spanview
|
||||
[spanview-debugging]: compiler-debugging.md#viewing-spanview-output
|
||||
[`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage-llvmir
|
||||
[`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-llvmir
|
||||
|
||||
## Implementation Details of the `InstrumentCoverage` MIR Pass
|
||||
|
||||
|
|
|
|||
|
|
@ -28,13 +28,13 @@ optimizes it, and returns the improved MIR.
|
|||
|
||||
## Quickstart for adding a new optimization
|
||||
|
||||
1. Make a Rust source file in `src/test/mir-opt` that shows the code you want to
|
||||
1. Make a Rust source file in `tests/mir-opt` that shows the code you want to
|
||||
optimize. This should be kept simple, so avoid `println!` or other formatting
|
||||
code if it's not necessary for the optimization. The reason for this is that
|
||||
`println!`, `format!`, etc. generate a lot of MIR that can make it harder to
|
||||
understand what the optimization does to the test.
|
||||
|
||||
2. Run `./x.py test --bless src/test/mir-opt/<your-test>.rs` to generate a MIR
|
||||
2. Run `./x.py test --bless tests/mir-opt/<your-test>.rs` to generate a MIR
|
||||
dump. Read [this README][mir-opt-test-readme] for instructions on how to dump
|
||||
things.
|
||||
|
||||
|
|
@ -51,10 +51,10 @@ optimizes it, and returns the improved MIR.
|
|||
[`run_optimization_passes()`] function,
|
||||
3. and then start modifying the copied optimization.
|
||||
|
||||
5. Rerun `./x.py test --bless src/test/mir-opt/<your-test>.rs` to regenerate the
|
||||
5. Rerun `./x.py test --bless tests/mir-opt/<your-test>.rs` to regenerate the
|
||||
MIR dumps. Look at the diffs to see if they are what you expect.
|
||||
|
||||
6. Run `./x.py test src/test/ui` to see if your optimization broke anything.
|
||||
6. Run `./x.py test tests/ui` to see if your optimization broke anything.
|
||||
|
||||
7. If there are issues with your optimization, experiment with it a bit and
|
||||
repeat steps 5 and 6.
|
||||
|
|
@ -70,7 +70,7 @@ optimizes it, and returns the improved MIR.
|
|||
If you have any questions along the way, feel free to ask in
|
||||
`#t-compiler/wg-mir-opt` on Zulip.
|
||||
|
||||
[mir-opt-test-readme]: https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md
|
||||
[mir-opt-test-readme]: https://github.com/rust-lang/rust/blob/master/tests/mir-opt/README.md
|
||||
[`compiler/rustc_mir_transform/src`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir_transform/src
|
||||
<!--- TODO: Change NoLandingPads. [#1232](https://github.com/rust-lang/rustc-dev-guide/issues/1232) -->
|
||||
[`no_landing_pads`]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_transform/src/no_landing_pads.rs
|
||||
|
|
|
|||
|
|
@ -131,8 +131,8 @@ in [run-make tests][rmake-tests] (the relevant tests have `pgo` in their name).
|
|||
There is also a [codegen test][codegen-test] that checks that some expected
|
||||
instrumentation artifacts show up in LLVM IR.
|
||||
|
||||
[rmake-tests]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps
|
||||
[codegen-test]: https://github.com/rust-lang/rust/blob/master/src/test/codegen/pgo-instrumentation.rs
|
||||
[rmake-tests]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps
|
||||
[codegen-test]: https://github.com/rust-lang/rust/blob/master/tests/codegen/pgo-instrumentation.rs
|
||||
|
||||
## Additional Information
|
||||
|
||||
|
|
|
|||
|
|
@ -191,7 +191,7 @@ Some extra reading about `make_test` can be found
|
|||
|
||||
So that's rustdoc's code in a nutshell, but there's more things in the repo
|
||||
that deal with it. Since we have the full `compiletest` suite at hand, there's
|
||||
a set of tests in `src/test/rustdoc` that make sure the final HTML is what we
|
||||
a set of tests in `tests/rustdoc` that make sure the final HTML is what we
|
||||
expect in various situations. These tests also use a supplementary script,
|
||||
`src/etc/htmldocck.py`, that allows it to look through the final HTML using
|
||||
XPath notation to get a precise look at the output. The full description of all
|
||||
|
|
@ -204,7 +204,7 @@ directory relative to the test file with the comment. If you need to build
|
|||
docs for the auxiliary file, use `// build-aux-docs`.
|
||||
|
||||
In addition, there are separate tests for the search index and rustdoc's
|
||||
ability to query it. The files in `src/test/rustdoc-js` each contain a
|
||||
ability to query it. The files in `tests/rustdoc-js` each contain a
|
||||
different search query and the expected results, broken out by search tab.
|
||||
These files are processed by a script in `src/tools/rustdoc-js` and the Node.js
|
||||
runtime. These tests don't have as thorough of a writeup, but a broad example
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
|
|||
* If you want to copy those docs to a webserver, copy all of
|
||||
`build/host/doc`, since that's where the CSS, JS, fonts, and landing
|
||||
page are.
|
||||
* Use `./x.py test src/test/rustdoc*` to run the tests using a stage1
|
||||
* Use `./x.py test tests/rustdoc*` to run the tests using a stage1
|
||||
rustdoc.
|
||||
* See [Rustdoc internals] for more information about tests.
|
||||
|
||||
|
|
@ -72,13 +72,13 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
|
|||
`doctest.rs`.
|
||||
* The Markdown renderer is loaded up in `html/markdown.rs`, including functions
|
||||
for extracting doctests from a given block of Markdown.
|
||||
* The tests on the structure of rustdoc HTML output are located in `src/test/rustdoc`, where
|
||||
* The tests on the structure of rustdoc HTML output are located in `tests/rustdoc`, where
|
||||
they're handled by the test runner of rustbuild and the supplementary script
|
||||
`src/etc/htmldocck.py`.
|
||||
|
||||
## Tests
|
||||
|
||||
* All paths in this section are relative to `src/test` in the rust-lang/rust repository.
|
||||
* All paths in this section are relative to `tests` in the rust-lang/rust repository.
|
||||
* Tests on search index generation are located in `rustdoc-js`, as a
|
||||
series of JavaScript files that encode queries on the standard library search
|
||||
index and expected results.
|
||||
|
|
|
|||
|
|
@ -76,8 +76,8 @@ implementation:
|
|||
## Testing sanitizers
|
||||
|
||||
Sanitizers are validated by code generation tests in
|
||||
[`src/test/codegen/sanitize*.rs`][test-cg] and end-to-end functional tests in
|
||||
[`src/test/ui/sanitize/`][test-ui] directory.
|
||||
[`tests/codegen/sanitize*.rs`][test-cg] and end-to-end functional tests in
|
||||
[`tests/ui/sanitize/`][test-ui] directory.
|
||||
|
||||
Testing sanitizer functionality requires the sanitizer runtimes (built when
|
||||
`sanitizer = true` in `config.toml`) and target providing support for particular
|
||||
|
|
@ -85,8 +85,8 @@ sanitizer. When sanitizer is unsupported on given target, sanitizers tests will
|
|||
be ignored. This behaviour is controlled by compiletest `needs-sanitizer-*`
|
||||
directives.
|
||||
|
||||
[test-cg]: https://github.com/rust-lang/rust/tree/master/src/test/codegen
|
||||
[test-ui]: https://github.com/rust-lang/rust/tree/master/src/test/ui/sanitize
|
||||
[test-cg]: https://github.com/rust-lang/rust/tree/master/tests/codegen
|
||||
[test-ui]: https://github.com/rust-lang/rust/tree/master/tests/ui/sanitize
|
||||
|
||||
## Enabling sanitizer on a new target
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ To enable a sanitizer on a new target which is already supported by LLVM:
|
|||
2. [Build the runtime for the target and include it in the libdir.][sanitizer-targets]
|
||||
3. [Teach compiletest that your target now supports the sanitizer.][compiletest-definition]
|
||||
Tests marked with `needs-sanitizer-*` should now run on the target.
|
||||
4. Run tests `./x.py test --force-rerun src/test/ui/sanitize/` to verify.
|
||||
4. Run tests `./x.py test --force-rerun tests/ui/sanitize/` to verify.
|
||||
5. [--enable-sanitizers in the CI configuration][ci-configuration] to build and
|
||||
distribute the sanitizer runtime as part of the release process.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ This will depend on the nature of the change and what you want to exercise.
|
|||
Here are some rough guidelines:
|
||||
|
||||
- The majority of compiler tests are done with [compiletest].
|
||||
- The majority of compiletest tests are [UI](ui.md) tests in the [`src/test/ui`] directory.
|
||||
- The majority of compiletest tests are [UI](ui.md) tests in the [`tests/ui`] directory.
|
||||
- Changes to the standard library are usually tested within the standard library itself.
|
||||
- The majority of standard library tests are written as doctests,
|
||||
which illustrate and exercise typical API behavior.
|
||||
|
|
@ -30,7 +30,7 @@ Here are some rough guidelines:
|
|||
- Check out the [compiletest] chapter for more specialized test suites.
|
||||
|
||||
[compiletest]: compiletest.md
|
||||
[`src/test/ui`]: https://github.com/rust-lang/rust/tree/master/src/test/ui/
|
||||
[`tests/ui`]: https://github.com/rust-lang/rust/tree/master/tests/ui/
|
||||
|
||||
## UI test walkthrough
|
||||
|
||||
|
|
@ -41,13 +41,13 @@ For this tutorial, we'll be adding a test for an async error message.
|
|||
### Step 1. Add a test file
|
||||
|
||||
The first step is to create a Rust source file somewhere in the
|
||||
[`src/test/ui`] tree.
|
||||
[`tests/ui`] tree.
|
||||
When creating a test, do your best to find a good location and name (see [Test
|
||||
organization](ui.md#test-organization) for more).
|
||||
Since naming is the hardest part of development, everything should be downhill
|
||||
from here!
|
||||
|
||||
Let's place our async test at `src/test/ui/async-await/await-without-async.rs`:
|
||||
Let's place our async test at `tests/ui/async-await/await-without-async.rs`:
|
||||
|
||||
```rust,ignore
|
||||
// Check what happens when using await in a non-async fn.
|
||||
|
|
@ -84,17 +84,17 @@ The next step is to create the expected output from the compiler.
|
|||
This can be done with the `--bless` option:
|
||||
|
||||
```sh
|
||||
./x.py test src/test/ui/async-await/await-without-async.rs --bless
|
||||
./x.py test tests/ui/async-await/await-without-async.rs --bless
|
||||
```
|
||||
|
||||
This will build the compiler (if it hasn't already been built), compile the
|
||||
test, and place the output of the compiler in a file called
|
||||
`src/test/ui/async-await/await-without-async.stderr`.
|
||||
`tests/ui/async-await/await-without-async.stderr`.
|
||||
|
||||
However, this step will fail!
|
||||
You should see an error message, something like this:
|
||||
|
||||
> error: /rust/src/test/ui/async-await/await-without-async.rs:7: unexpected
|
||||
> error: /rust/tests/ui/async-await/await-without-async.rs:7: unexpected
|
||||
> error: '7:10: 7:16: `await` is only allowed inside `async` functions and
|
||||
> blocks E0728'
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ annotations](ui.md#error-annotations) section).
|
|||
Save that, and run the test again:
|
||||
|
||||
```sh
|
||||
./x.py test src/test/ui/async-await/await-without-async.rs
|
||||
./x.py test tests/ui/async-await/await-without-async.rs
|
||||
```
|
||||
|
||||
It should now pass, yay!
|
||||
|
|
@ -131,7 +131,7 @@ If you are adding a new diagnostic message, now would be a good time to
|
|||
also consider how readable the message looks overall, particularly for
|
||||
people new to Rust.
|
||||
|
||||
Our example `src/test/ui/async-await/await-without-async.stderr` file should
|
||||
Our example `tests/ui/async-await/await-without-async.stderr` file should
|
||||
look like this:
|
||||
|
||||
```text
|
||||
|
|
@ -166,7 +166,7 @@ The final step before posting a PR is to check if you have affected anything els
|
|||
Running the UI suite is usually a good start:
|
||||
|
||||
```sh
|
||||
./x.py test src/test/ui
|
||||
./x.py test tests/ui
|
||||
```
|
||||
|
||||
If other tests start failing, you may need to investigate what has changed
|
||||
|
|
|
|||
|
|
@ -26,11 +26,11 @@ suite.
|
|||
|
||||
## Test suites
|
||||
|
||||
All of the tests are in the [`src/test`] directory.
|
||||
All of the tests are in the [`tests`] directory.
|
||||
The tests are organized into "suites", with each suite in a separate subdirectory.
|
||||
Each test suite behaves a little differently, with different compiler behavior
|
||||
and different checks for correctness.
|
||||
For example, the [`src/test/incremental`] directory contains tests for
|
||||
For example, the [`tests/incremental`] directory contains tests for
|
||||
incremental compilation.
|
||||
The various suites are defined in [`src/tools/compiletest/src/common.rs`] in
|
||||
the `pub enum Mode` declaration.
|
||||
|
|
@ -62,12 +62,12 @@ The following test suites are available, with links for more information:
|
|||
- `rustdoc-json` — tests on the JSON output of rustdoc.
|
||||
- `rustdoc-ui` — tests on the terminal output of rustdoc.
|
||||
|
||||
[`src/test`]: https://github.com/rust-lang/rust/blob/master/src/test
|
||||
[`tests`]: https://github.com/rust-lang/rust/blob/master/tests
|
||||
[`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs
|
||||
|
||||
### Pretty-printer tests
|
||||
|
||||
The tests in [`src/test/pretty`] exercise the "pretty-printing" functionality of `rustc`.
|
||||
The tests in [`tests/pretty`] exercise the "pretty-printing" functionality of `rustc`.
|
||||
The `-Z unpretty` CLI option for `rustc` causes it to translate the input source
|
||||
into various different formats, such as the Rust source after macro expansion.
|
||||
|
||||
|
|
@ -119,11 +119,11 @@ The header commands for pretty-printing tests are:
|
|||
pretty-printing rounds will be compared to ensure that the pretty-printed
|
||||
output converges to a steady state.
|
||||
|
||||
[`src/test/pretty`]: https://github.com/rust-lang/rust/tree/master/src/test/pretty
|
||||
[`tests/pretty`]: https://github.com/rust-lang/rust/tree/master/tests/pretty
|
||||
|
||||
### Incremental tests
|
||||
|
||||
The tests in [`src/test/incremental`] exercise incremental compilation.
|
||||
The tests in [`tests/incremental`] exercise incremental compilation.
|
||||
They use [revision headers](#revisions) to tell compiletest to run the
|
||||
compiler in a series of steps.
|
||||
Compiletest starts with an empty directory with the `-C incremental` flag, and
|
||||
|
|
@ -168,12 +168,12 @@ cause an Internal Compiler Error (ICE).
|
|||
This is a highly specialized header to check that the incremental cache
|
||||
continues to work after an ICE.
|
||||
|
||||
[`src/test/incremental`]: https://github.com/rust-lang/rust/tree/master/src/test/incremental
|
||||
[`tests/incremental`]: https://github.com/rust-lang/rust/tree/master/tests/incremental
|
||||
|
||||
|
||||
### Debuginfo tests
|
||||
|
||||
The tests in [`src/test/debuginfo`] test debuginfo generation.
|
||||
The tests in [`tests/debuginfo`] test debuginfo generation.
|
||||
They build a program, launch a debugger, and issue commands to the debugger.
|
||||
A single test can work with cdb, gdb, and lldb.
|
||||
|
||||
|
|
@ -237,12 +237,12 @@ test based on the debugger currently being used:
|
|||
NOTE: The "Rust" version of LLDB doesn't exist anymore, so this will always be ignored.
|
||||
This should probably be removed.
|
||||
|
||||
[`src/test/debuginfo`]: https://github.com/rust-lang/rust/tree/master/src/test/debuginfo
|
||||
[`tests/debuginfo`]: https://github.com/rust-lang/rust/tree/master/tests/debuginfo
|
||||
|
||||
|
||||
### Codegen tests
|
||||
|
||||
The tests in [`src/test/codegen`] test LLVM code generation.
|
||||
The tests in [`tests/codegen`] test LLVM code generation.
|
||||
They compile the test with the `--emit=llvm-ir` flag to emit LLVM IR.
|
||||
They then run the LLVM [FileCheck] tool.
|
||||
The test is annotated with various `// CHECK` comments to check the generated code.
|
||||
|
|
@ -250,13 +250,13 @@ See the FileCheck documentation for a tutorial and more information.
|
|||
|
||||
See also the [assembly tests](#assembly-tests) for a similar set of tests.
|
||||
|
||||
[`src/test/codegen`]: https://github.com/rust-lang/rust/tree/master/src/test/codegen
|
||||
[`tests/codegen`]: https://github.com/rust-lang/rust/tree/master/tests/codegen
|
||||
[FileCheck]: https://llvm.org/docs/CommandGuide/FileCheck.html
|
||||
|
||||
|
||||
### Assembly tests
|
||||
|
||||
The tests in [`src/test/assembly`] test LLVM assembly output.
|
||||
The tests in [`tests/assembly`] test LLVM assembly output.
|
||||
They compile the test with the `--emit=asm` flag to emit a `.s` file with the
|
||||
assembly output.
|
||||
They then run the LLVM [FileCheck] tool.
|
||||
|
|
@ -271,12 +271,12 @@ See the FileCheck documentation for a tutorial and more information.
|
|||
|
||||
See also the [codegen tests](#codegen-tests) for a similar set of tests.
|
||||
|
||||
[`src/test/assembly`]: https://github.com/rust-lang/rust/tree/master/src/test/assembly
|
||||
[`tests/assembly`]: https://github.com/rust-lang/rust/tree/master/tests/assembly
|
||||
|
||||
|
||||
### Codegen-units tests
|
||||
|
||||
The tests in [`src/test/codegen-units`] test the
|
||||
The tests in [`tests/codegen-units`] test the
|
||||
[monomorphization](../backend/monomorph.md) collector and CGU partitioning.
|
||||
|
||||
These tests work by running `rustc` with a flag to print the result of the
|
||||
|
|
@ -295,12 +295,12 @@ where `cgu` is a space separated list of the CGU names and the linkage
|
|||
information in brackets.
|
||||
For example: `//~ MONO_ITEM static function::FOO @@ statics[Internal]`
|
||||
|
||||
[`src/test/codegen-units`]: https://github.com/rust-lang/rust/tree/master/src/test/codegen-units
|
||||
[`tests/codegen-units`]: https://github.com/rust-lang/rust/tree/master/tests/codegen-units
|
||||
|
||||
|
||||
### Mir-opt tests
|
||||
|
||||
The tests in [`src/test/mir-opt`] check parts of the generated MIR to make
|
||||
The tests in [`tests/mir-opt`] check parts of the generated MIR to make
|
||||
sure it is generated correctly and is doing the expected optimizations.
|
||||
Check out the [MIR Optimizations](../mir/optimizations.md) chapter for more.
|
||||
|
||||
|
|
@ -345,12 +345,12 @@ problematic in the presence of pointers in constants or other bit width
|
|||
dependent things. In that case you can add `// EMIT_MIR_FOR_EACH_BIT_WIDTH` to
|
||||
your test, causing separate files to be generated for 32bit and 64bit systems.
|
||||
|
||||
[`src/test/mir-opt`]: https://github.com/rust-lang/rust/tree/master/src/test/mir-opt
|
||||
[`tests/mir-opt`]: https://github.com/rust-lang/rust/tree/master/tests/mir-opt
|
||||
|
||||
|
||||
### Run-make tests
|
||||
|
||||
The tests in [`src/test/run-make`] are general-purpose tests using Makefiles
|
||||
The tests in [`tests/run-make`] are general-purpose tests using Makefiles
|
||||
which provide the ultimate in flexibility.
|
||||
These should be used as a last resort.
|
||||
If possible, you should use one of the other test suites.
|
||||
|
|
@ -365,18 +365,18 @@ There is a [`tools.mk`] Makefile which you can include which provides a bunch of
|
|||
utilities to make it easier to run commands and compare outputs.
|
||||
Take a look at some of the other tests for some examples on how to get started.
|
||||
|
||||
[`tools.mk`]: https://github.com/rust-lang/rust/blob/master/src/test/run-make-fulldeps/tools.mk
|
||||
[`src/test/run-make`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make
|
||||
[`tools.mk`]: https://github.com/rust-lang/rust/blob/master/tests/run-make-fulldeps/tools.mk
|
||||
[`tests/run-make`]: https://github.com/rust-lang/rust/tree/master/tests/run-make
|
||||
|
||||
|
||||
### Valgrind tests
|
||||
|
||||
The tests in [`src/test/run-pass-valgrind`] are for use with [Valgrind].
|
||||
The tests in [`tests/run-pass-valgrind`] are for use with [Valgrind].
|
||||
These are currently vestigial, as Valgrind is no longer used in CI.
|
||||
These may be removed in the future.
|
||||
|
||||
[Valgrind]: https://valgrind.org/
|
||||
[`src/test/run-pass-valgrind`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass-valgrind
|
||||
[`tests/run-pass-valgrind`]: https://github.com/rust-lang/rust/tree/master/tests/run-pass-valgrind
|
||||
|
||||
|
||||
## Building auxiliary crates
|
||||
|
|
@ -501,7 +501,7 @@ To run the tests in a different mode, you need to pass the `--compare-mode`
|
|||
CLI flag:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui --compare-mode=chalk
|
||||
./x.py test tests/ui --compare-mode=chalk
|
||||
```
|
||||
|
||||
The possible compare modes are:
|
||||
|
|
@ -517,10 +517,10 @@ tests support different output for different modes.
|
|||
In CI, compare modes are only used in one Linux builder, and only with the
|
||||
following settings:
|
||||
|
||||
* `src/test/debuginfo`: Uses `split-dwarf` mode.
|
||||
* `tests/debuginfo`: Uses `split-dwarf` mode.
|
||||
This helps ensure that none of the debuginfo tests are affected when
|
||||
enabling split-DWARF.
|
||||
|
||||
Note that compare modes are separate to [revisions](#revisions).
|
||||
All revisions are tested when running `./x.py test src/test/ui`, however
|
||||
All revisions are tested when running `./x.py test tests/ui`, however
|
||||
compare-modes must be manually run individually via the `--compare-mode` flag.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ directory. From there, you can run `../src/ci/run.sh` which will run the build
|
|||
as defined by the image.
|
||||
|
||||
Alternatively, you can run individual commands to do specific tasks. For
|
||||
example, you can run `python3 ../x.py test src/test/ui` to just run UI tests.
|
||||
example, you can run `python3 ../x.py test tests/ui` to just run UI tests.
|
||||
Note that there is some configuration in the [`src/ci/run.sh`] script that you
|
||||
may need to recreate. Particularly, set `submodules = false` in your
|
||||
`config.toml` so that it doesn't attempt to modify the read-only directory.
|
||||
|
|
|
|||
|
|
@ -244,12 +244,12 @@ described below:
|
|||
- Examples: `/path/to/rust`, `/path/to/build/root`
|
||||
- `{{src-base}}`: The directory where the test is defined. This is equivalent to
|
||||
`$DIR` for [output normalization].
|
||||
- Example: `/path/to/rust/src/test/ui/error-codes`
|
||||
- Example: `/path/to/rust/tests/ui/error-codes`
|
||||
- `{{build-base}}`: The base directory where the test's output goes. This is
|
||||
equivalent to `$TEST_BUILD_DIR` for [output normalization].
|
||||
- Example: `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui`
|
||||
|
||||
See [`src/test/ui/commandline-argfile.rs`](https://github.com/rust-lang/rust/blob/a5029ac0ab372aec515db2e718da6d7787f3d122/src/test/ui/commandline-argfile.rs)
|
||||
See [`tests/ui/commandline-argfile.rs`](https://github.com/rust-lang/rust/blob/master/tests/ui/commandline-argfile.rs)
|
||||
for an example of a test that uses this substitution.
|
||||
|
||||
[output normalization]: ui.md#normalization
|
||||
|
|
|
|||
|
|
@ -16,13 +16,13 @@ Almost all of them are driven by `./x.py test`, with some exceptions noted below
|
|||
|
||||
The main test harness for testing the compiler itself is a tool called [compiletest].
|
||||
It supports running different styles of tests, called *test suites*.
|
||||
The tests are all located in the [`src/test`] directory.
|
||||
The tests are all located in the [`tests`] directory.
|
||||
The [Compiletest chapter][compiletest] goes into detail on how to use this tool.
|
||||
|
||||
> Example: `./x.py test src/test/ui`
|
||||
> Example: `./x.py test tests/ui`
|
||||
|
||||
[compiletest]: compiletest.md
|
||||
[`src/test`]: https://github.com/rust-lang/rust/tree/master/src/test
|
||||
[`tests`]: https://github.com/rust-lang/rust/tree/master/tests
|
||||
|
||||
### Package tests
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ modifying rustc to see if things are generally working correctly would be the
|
|||
following:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui
|
||||
./x.py test tests/ui
|
||||
```
|
||||
|
||||
This will run the `ui` test suite. Of course, the choice
|
||||
|
|
@ -46,20 +46,20 @@ doing. For example, if you are hacking on debuginfo, you may be better off
|
|||
with the debuginfo test suite:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/debuginfo
|
||||
./x.py test tests/debuginfo
|
||||
```
|
||||
|
||||
If you only need to test a specific subdirectory of tests for any
|
||||
given test suite, you can pass that directory to `./x.py test`:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui/const-generics
|
||||
./x.py test tests/ui/const-generics
|
||||
```
|
||||
|
||||
Likewise, you can test a single file by passing its path:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui/const-generics/const-test.rs
|
||||
./x.py test tests/ui/const-generics/const-test.rs
|
||||
```
|
||||
|
||||
### Run only the tidy script
|
||||
|
|
@ -125,7 +125,7 @@ you may pass the full file path to achieve this, or alternatively one
|
|||
may invoke `x.py` with the `--test-args` option:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui --test-args issue-1234
|
||||
./x.py test tests/ui --test-args issue-1234
|
||||
```
|
||||
|
||||
Under the hood, the test runner invokes the standard Rust test runner
|
||||
|
|
@ -137,10 +137,10 @@ filtering for tests that include "issue-1234" in the name. (Thus
|
|||
|
||||
If you have changed the compiler's output intentionally, or you are
|
||||
making a new test, you can pass `--bless` to the test subcommand. E.g.
|
||||
if some tests in `src/test/ui` are failing, you can run
|
||||
if some tests in `tests/ui` are failing, you can run
|
||||
|
||||
```text
|
||||
./x.py test src/test/ui --bless
|
||||
./x.py test tests/ui --bless
|
||||
```
|
||||
|
||||
to automatically adjust the `.stderr`, `.stdout` or `.fixed` files of
|
||||
|
|
@ -165,10 +165,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/ui` as `check-pass`:
|
||||
`tests/ui` as `check-pass`:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui --pass check
|
||||
./x.py test tests/ui --pass check
|
||||
```
|
||||
|
||||
By passing `--pass $mode`, you can reduce the testing time. For each
|
||||
|
|
@ -181,7 +181,7 @@ You can further enable the `--incremental` flag to save additional
|
|||
time in subsequent rebuilds:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui --incremental --test-args issue-1234
|
||||
./x.py test tests/ui --incremental --test-args issue-1234
|
||||
```
|
||||
|
||||
If you don't want to include the flag with every command, you can
|
||||
|
|
@ -205,7 +205,7 @@ mode, a test `foo.rs` will first look for expected output in
|
|||
The following will run the UI test suite in Polonius mode:
|
||||
|
||||
```bash
|
||||
./x.py test src/test/ui --compare-mode=polonius
|
||||
./x.py test tests/ui --compare-mode=polonius
|
||||
```
|
||||
|
||||
See [Compare modes](compiletest.md#compare-modes) for more details.
|
||||
|
|
@ -218,7 +218,7 @@ Most tests are just `rs` files, so after
|
|||
you can do something like:
|
||||
|
||||
```bash
|
||||
rustc +stage1 src/test/ui/issue-1234.rs
|
||||
rustc +stage1 tests/ui/issue-1234.rs
|
||||
```
|
||||
|
||||
This is much faster, but doesn't always work. For example, some tests
|
||||
|
|
@ -272,7 +272,7 @@ variable then use `x.py` as usual. For example, to run `ui` tests for a RISC-V
|
|||
machine with the IP address `1.2.3.4` use
|
||||
```sh
|
||||
export TEST_DEVICE_ADDR="1.2.3.4:12345"
|
||||
./x.py test src/test/ui --target riscv64gc-unknown-linux-gnu
|
||||
./x.py test tests/ui --target riscv64gc-unknown-linux-gnu
|
||||
```
|
||||
|
||||
If `remote-test-server` was run with the verbose flag, output on the test machine
|
||||
|
|
|
|||
|
|
@ -6,18 +6,18 @@ UI tests are a particular [test suite](compiletest.md#test-suites) of compiletes
|
|||
|
||||
## Introduction
|
||||
|
||||
The tests in [`src/test/ui`] are a collection of general-purpose tests which
|
||||
The tests in [`tests/ui`] are a collection of general-purpose tests which
|
||||
primarily focus on validating the console output of the compiler, but can be
|
||||
used for many other purposes.
|
||||
For example, tests can also be configured to [run the resulting
|
||||
program](#controlling-passfail-expectations) to verify its behavior.
|
||||
|
||||
[`src/test/ui`]: https://github.com/rust-lang/rust/blob/master/src/test/ui
|
||||
[`tests/ui`]: https://github.com/rust-lang/rust/blob/master/tests/ui
|
||||
|
||||
## General structure of a test
|
||||
|
||||
A test consists of a Rust source file located anywhere in the `src/test/ui` directory.
|
||||
For example, [`src/test/ui/hello.rs`] is a basic hello-world test.
|
||||
A test consists of a Rust source file located anywhere in the `tests/ui` directory.
|
||||
For example, [`tests/ui/hello.rs`] is a basic hello-world test.
|
||||
|
||||
Compiletest will use `rustc` to compile the test, and compare the output
|
||||
against the expected output which is stored in a `.stdout` or `.stderr` file
|
||||
|
|
@ -40,7 +40,7 @@ By default, a test is built as an executable binary.
|
|||
If you need a different crate type, you can use the `#![crate_type]` attribute
|
||||
to set it as needed.
|
||||
|
||||
[`src/test/ui/hello.rs`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello.rs
|
||||
[`tests/ui/hello.rs`]: https://github.com/rust-lang/rust/blob/master/tests/ui/hello.rs
|
||||
|
||||
## Output comparison
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ platforms, mainly about filenames.
|
|||
Compiletest makes the following replacements on the compiler output:
|
||||
|
||||
- The directory where the test is defined is replaced with `$DIR`.
|
||||
Example: `/path/to/rust/src/test/ui/error-codes`
|
||||
Example: `/path/to/rust/tests/ui/error-codes`
|
||||
- The directory to the standard library source is replaced with `$SRC_DIR`.
|
||||
Example: `/path/to/rust/library`
|
||||
- Line and column numbers for paths in `$SRC_DIR` are replaced with `LL:COL`.
|
||||
|
|
@ -160,8 +160,8 @@ The corresponding reference file will use the normalized output to test both
|
|||
Please see [`ui/transmute/main.rs`][mrs] and [`main.stderr`] for a
|
||||
concrete usage example.
|
||||
|
||||
[mrs]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.rs
|
||||
[`main.stderr`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr
|
||||
[mrs]: https://github.com/rust-lang/rust/blob/master/tests/ui/transmute/main.rs
|
||||
[`main.stderr`]: https://github.com/rust-lang/rust/blob/master/tests/ui/transmute/main.stderr
|
||||
|
||||
Besides `normalize-stderr-32bit` and `-64bit`, one may use any target
|
||||
information or stage supported by [`ignore-X`](headers.md#ignoring-tests)
|
||||
|
|
@ -387,7 +387,7 @@ Tests with the `*-pass` headers can be overridden with the `--pass`
|
|||
command-line option:
|
||||
|
||||
```sh
|
||||
./x.py test src/test/ui --pass check
|
||||
./x.py test tests/ui --pass check
|
||||
```
|
||||
|
||||
The `--pass` option only affects UI tests.
|
||||
|
|
@ -426,30 +426,30 @@ from the internet – we often name the test after the issue plus a short
|
|||
description.
|
||||
Ideally, the test should be added to a directory that helps identify what
|
||||
piece of code is being tested here (e.g.,
|
||||
`src/test/ui/borrowck/issue-54597-reject-move-out-of-borrow-via-pat.rs`)
|
||||
`tests/ui/borrowck/issue-54597-reject-move-out-of-borrow-via-pat.rs`)
|
||||
|
||||
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 a directory like `src/test/ui/rfc1234-widgets/`.
|
||||
sense to put the tests in a directory like `tests/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.)
|
||||
|
||||
Over time, the [`src/test/ui`] directory has grown very fast.
|
||||
Over time, the [`tests/ui`] directory has grown very fast.
|
||||
There is a check in [tidy](intro.md#tidy) that will ensure none of the
|
||||
subdirectories has more than 1000 entries.
|
||||
Having too many files causes problems because it isn't editor/IDE friendly and
|
||||
the GitHub UI won't show more than 1000 entries.
|
||||
However, since `src/test/ui` (UI test root directory) and `src/test/ui/issues`
|
||||
However, since `tests/ui` (UI test root directory) and `tests/ui/issues`
|
||||
directories have more than 1000 entries, we set a different limit for those
|
||||
directories.
|
||||
So, please avoid putting a new test there and try to find a more relevant
|
||||
place.
|
||||
|
||||
For example, if your test is related to closures, you should put it in
|
||||
`src/test/ui/closures`.
|
||||
`tests/ui/closures`.
|
||||
If you're not sure where is the best place, it's still okay to add to
|
||||
`src/test/ui/issues/`.
|
||||
`tests/ui/issues/`.
|
||||
When you reach the limit, you could increase it by tweaking [here][ui test
|
||||
tidy].
|
||||
|
||||
|
|
@ -512,7 +512,7 @@ If in the rare case you encounter a test that has different behavior, you can
|
|||
run something like the following to generate the alternate stderr file:
|
||||
|
||||
```sh
|
||||
./x.py test src/test/ui --compare-mode=polonius --bless
|
||||
./x.py test tests/ui --compare-mode=polonius --bless
|
||||
```
|
||||
|
||||
Currently none of the compare modes are checked in CI for UI tests.
|
||||
|
|
|
|||
Loading…
Reference in New Issue