Change src/test to tests (rust-lang#1547)

Author: albertlarsan68

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

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

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

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

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

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

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,17 +76,17 @@ 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
 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.
 

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