Change src/test to tests (#1547)

Author: albertlarsan68

src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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