Change `src/test` to `tests` (#1547)

src/appendix/humorust.md

@@ -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)

src/asm.md

@@ -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`
+- `tests/assembly/asm`
-- `src/test/ui/asm`
+- `tests/ui/asm`
-- `src/test/codegen/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.

src/building/bootstrapping.md

@@ -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
+- `./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 src/test/ui`
+  _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.
 

src/building/how-to-build-and-run.md

@@ -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 tests/ui` – runs the `ui` test suite
-  - `./x.py test src/test/ui/const-generics` - runs all the tests in
+  - `./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

src/building/suggested.md

@@ -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`
+- Initial test run: `./x.py test tests/ui`
-- Subsequent test run: `./x.py test src/test/ui --keep-stage 1`
+- Subsequent test run: `./x.py test tests/ui --keep-stage 1`
 
 ## Fine-tuning optimizations
 

src/compiler-src.md

@@ -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

src/incrcomp-debugging.md

@@ -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:
 

src/llvm-coverage-instrumentation.md

@@ -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
+[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/src/test/run-make-fulldeps/coverage
+[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/src/test/run-make-fulldeps/coverage-reports
+[`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/src/test/run-make-fulldeps/coverage-spanview
+[`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
 

src/mir/optimizations.md

@@ -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

src/profile-guided-optimization.md

@@ -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
+[rmake-tests]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps
-[codegen-test]: https://github.com/rust-lang/rust/blob/master/src/test/codegen/pgo-instrumentation.rs
+[codegen-test]: https://github.com/rust-lang/rust/blob/master/tests/codegen/pgo-instrumentation.rs
 
 ## Additional Information
 

src/rustdoc-internals.md

@@ -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

src/rustdoc.md

@@ -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.

src/sanitizers.md

@@ -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
+[`tests/codegen/sanitize*.rs`][test-cg] and end-to-end functional tests in
-[`src/test/ui/sanitize/`][test-ui] directory.
+[`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-cg]: https://github.com/rust-lang/rust/tree/master/tests/codegen
-[test-ui]: https://github.com/rust-lang/rust/tree/master/src/test/ui/sanitize
+[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.
 

src/tests/adding.md

@@ -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

src/tests/compiletest.md

@@ -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
+[`tools.mk`]: https://github.com/rust-lang/rust/blob/master/tests/run-make-fulldeps/tools.mk
-[`src/test/run-make`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make
+[`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.

src/tests/docker.md

@@ -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.

src/tests/headers.md

@@ -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

src/tests/intro.md

@@ -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
 

src/tests/running.md

@@ -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

src/tests/ui.md

@@ -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.
+A test consists of a Rust source file located anywhere in the `tests/ui` directory.
-For example, [`src/test/ui/hello.rs`] is a basic hello-world test.
+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
+[mrs]: https://github.com/rust-lang/rust/blob/master/tests/ui/transmute/main.rs
-[`main.stderr`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr
+[`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.