run-pass dir is gone (#409)

Fixes #405

Author: tshepang

src/compiletest.md

@@ -16,8 +16,8 @@ expect, and more.  If you are unfamiliar with the compiler testing framework,
 see [this chapter](./tests/intro.html) for additional background.
 
 The tests themselves are typically (but not always) organized into
-"suites" – for example, `run-pass`, a folder representing tests that should
-succeed, `run-fail`, a folder holding tests that should compile successfully,
+"suites" – for example, `run-fail`,
+a folder holding tests that should compile successfully,
 but return a failure (non-zero status), `compile-fail`, a folder holding tests
 that should fail to compile, and many more.  The various suites are defined in
 [src/tools/compiletest/src/common.rs][common] in the `pub struct Config`

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

@@ -483,7 +483,7 @@ in other sections:
 - Running tests (see the [section on running tests](./tests/running.html) for
   more details):
   - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd
-  - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite
+  - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite
   - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in
   the `const-generics/` subdirectory of the `ui` test suite
   - `./x.py test --stage 1 src/test/ui/const-generics/const-types.rs` - runs

src/tests/adding.md

@@ -43,26 +43,23 @@ rough heuristics:
 We have not traditionally had a lot of structure in the names of
 tests.  Moreover, for a long time, the rustc test runner did not
 support subdirectories (it now does), so test suites like
-[`src/test/run-pass`] have a huge mess of files in them. This is not
+[`src/test/ui`] have a huge mess of files in them.  This is not
 considered an ideal setup.
 
-[`src/test/run-pass`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass/
+[`src/test/ui`]: https://github.com/rust-lang/rust/tree/master/src/test/ui/
 
 For regression tests – basically, some random snippet of code that
 came in from the internet – we often just name the test after the
-issue. For example, `src/test/run-pass/issue-12345.rs`. If possible,
+issue. For example, `src/test/ui/issue-12345.rs`. If possible,
 though, it is better if you can put the test into a directory that
 helps identify what piece of code is being tested here (e.g.,
 `borrowck/issue-12345.rs` is much better), or perhaps give it a more
 meaningful name. Still, **do include the issue number somewhere**.
 
 When writing a new feature, **create a subdirectory to store your
 tests**. For example, if you are implementing RFC 1234 ("Widgets"),
-then it might make sense to put the tests in directories like:
-
-- `src/test/ui/rfc1234-widgets/`
-- `src/test/run-pass/rfc1234-widgets/`
-- etc
+then it might make sense to put the tests in a directory like
+`src/test/ui/rfc1234-widgets/`.
 
 In other cases, there may already be a suitable directory. (The proper
 directory structure to use is actually an area of active debate.)
@@ -216,7 +213,7 @@ The error levels that you can have are:
 ## Revisions
 
 Certain classes of tests support "revisions" (as of the time of this
-writing, this includes run-pass, compile-fail, run-fail, and
+writing, this includes compile-fail, run-fail, and
 incremental, though incremental tests are somewhat
 different). Revisions allow a single test file to be used for multiple
 tests. This is done by adding a special header at the top of the file:

src/tests/running.md

@@ -34,10 +34,10 @@ test" that can be used after modifying rustc to see if things are
 generally working correctly would be the following:
 
 ```bash
-> ./x.py test --stage 1 src/test/{ui,compile-fail,run-pass}
+> ./x.py test --stage 1 src/test/{ui,compile-fail}
 ```
 
-This will run the `ui`, `compile-fail`, and `run-pass` test suites,
+This will run the `ui` and `compile-fail` test suites,
 and only with the stage 1 build. Of course, the choice of test suites
 is somewhat arbitrary, and may not suit the task you are doing. For
 example, if you are hacking on debuginfo, you may be better off with
@@ -114,10 +114,10 @@ Pass UI tests now have three modes, `check-pass`, `build-pass` and
 `run-pass`. When `--pass $mode` is passed, these tests will be forced
 to run under the given `$mode` unless the directive `// ignore-pass`
 exists in the test file. For example, you can run all the tests in
-`src/test/run-pass` as `check-pass`:
+`src/test/ui` as `check-pass`:
 
 ```bash
-> ./x.py test --stage 1 src/test/run-pass --pass check
+> ./x.py test --stage 1 src/test/ui --pass check
 ```
 
 By passing `--pass $mode`, you can reduce the testing time. For each