diff --git a/README.md b/README.md
index fdf6c5050..131651e38 100644
--- a/README.md
+++ b/README.md
@@ -118,7 +118,7 @@ git submodule update --remote src/doc/rustc-dev-guide
 git add -u
 git commit -m "Update rustc-dev-guide"
 # Note that you can use -i, which is short for --incremental, in the following command
-./x.py test --incremental src/doc/rustc-dev-guide # This is optional and should succeed anyway
+./x test --incremental src/doc/rustc-dev-guide # This is optional and should succeed anyway
 # Open a PR in rust-lang/rust
 ```
 
diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md
index a02011149..08af10f89 100644
--- a/src/backend/updating-llvm.md
+++ b/src/backend/updating-llvm.md
@@ -90,16 +90,16 @@ so let's go through each in detail.
    `src/llvm-project` to ensure submodule updates aren't reverted.
    Some commands you should execute are:
 
-   * `./x.py build src/llvm` - test that LLVM still builds
-   * `./x.py build src/tools/lld` - same for LLD
-   * `./x.py build` - build the rest of rustc
+   * `./x build src/llvm` - test that LLVM still builds
+   * `./x build src/tools/lld` - same for LLD
+   * `./x build` - build the rest of rustc
 
    You'll likely need to update [`llvm-wrapper/*.cpp`][`llvm-wrapper`]
    to compile with updated LLVM bindings.
    Note that you should use `#ifdef` and such to ensure
    that the bindings still compile on older LLVM versions.
 
-   Note that `profile = "compiler"` and other defaults set by `./x.py setup`
+   Note that `profile = "compiler"` and other defaults set by `./x setup`
    download LLVM from CI instead of building it from source.
    You should disable this temporarily to make sure your changes are being used.
    This is done by having the following setting in `config.toml`:
diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md
index 321ffbce0..388e39b93 100644
--- a/src/bug-fix-procedure.md
+++ b/src/bug-fix-procedure.md
@@ -325,7 +325,7 @@ general, if the test used to have `#[deny(overlapping_inherent_impls)]`, that
 can just be removed.
 
 ```
-./x.py test
+./x test
 ```
 
 #### All done!
diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md
index d53896f81..936c75f36 100644
--- a/src/building/bootstrapping.md
+++ b/src/building/bootstrapping.md
@@ -96,7 +96,7 @@ However, it takes a very long time to build
 because one must first build the new compiler with an older compiler
 and then use that to build the new compiler with itself.
 For development, you usually only want the `stage1` compiler,
-which you can build with `./x.py build library`.
+which you can build with `./x build library`.
 See [Building the compiler](./how-to-build-and-run.html#building-the-compiler).
 
 ### Stage 3: the same-result test
@@ -107,7 +107,7 @@ to be identical to before, unless something has broken.
 
 ### Building the stages
 
-`x.py` tries to be helpful and pick the stage you most likely meant for each subcommand.
+`x` tries to be helpful and pick the stage you most likely meant for each subcommand.
 These defaults are as follows:
 
 - `check`: `--stage 0`
@@ -152,7 +152,7 @@ bootstrapping the compiler.
 
 This is a detailed look into the separate bootstrap stages.
 
-The convention `x.py` uses is that:
+The convention `x` uses is that:
 
 - A `--stage N` flag means to run the stage N compiler (`stageN/rustc`).
 - A "stage N artifact" is a build artifact that is _produced_ by the stage N compiler.
@@ -161,7 +161,7 @@ The convention `x.py` uses is that:
 
 #### Build artifacts
 
-Anything you can build with `x.py` is a _build artifact_.
+Anything you can build with `x` is a _build artifact_.
 Build artifacts include, but are not limited to:
 
 - binaries, like `stage0-rustc/rustc-main`
@@ -173,27 +173,27 @@ Build artifacts include, but are not limited to:
 
 #### Examples
 
-- `./x.py build --stage 0` means to build with the beta `rustc`.
-- `./x.py doc --stage 0` means to document using the beta `rustdoc`.
-- `./x.py test --stage 0 library/std` means to run tests on the standard library
-    without building `rustc` from source ('build with stage 0, then test the
+- `./x build --stage 0` means to build with the beta `rustc`.
+- `./x doc --stage 0` means to document using the beta `rustdoc`.
+- `./x test --stage 0 library/std` means to run tests on the standard library
+  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 tests/ui` means to build the stage 1 compiler and run
+- `./x 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 tests/ui` is not useful: it runs tests on the
+- `./x 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:
+- `./x 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
   tests. You shouldn't need to use this, use `test` instead (without arguments).
-- `./x.py build --stage 0 compiler/rustc` builds the compiler, but does not build
-  libstd or even libcore. Most of the time, you'll want `./x.py build
-  library` instead, which allows compiling programs without needing to define
+- `./x build --stage 0 compiler/rustc` builds the compiler, but does not build
+  libstd or even libcore. Most of the time, you'll want `./x build
+library` instead, which allows compiling programs without needing to define
   lang items.
 
 ### Building vs. running
@@ -243,7 +243,7 @@ artifacts into the appropriate place, skipping the cargo invocation.
 For instance, you might want to build an ARM version of rustc using an x86 machine.
 Building stage2 `std` is different when you are cross-compiling.
 
-This is because `x.py` uses a trick: if `HOST` and `TARGET` are the same,
+This is because `x` uses a trick: if `HOST` and `TARGET` are the same,
 it will reuse stage1 `std` for stage2! This is sound because stage1 `std`
 was compiled with the stage1 compiler, i.e. a compiler using the source code
 you currently have checked out. So it should be identical (and therefore ABI-compatible)
@@ -362,7 +362,7 @@ You can find more discussion about sysroots in:
 
 ## Passing flags to commands invoked by `bootstrap`
 
-`x.py` allows you to pass stage-specific flags to `rustc` and `cargo` when bootstrapping.
+`x` allows you to pass stage-specific flags to `rustc` and `cargo` when bootstrapping.
 The `RUSTFLAGS_BOOTSTRAP` environment variable is passed as `RUSTFLAGS` to the bootstrap stage
 (stage0), and `RUSTFLAGS_NOT_BOOTSTRAP` is passed when building artifacts for later stages.
 `RUSTFLAGS` will work, but also affects the build of `bootstrap` itself, so it will be rare to want
@@ -395,7 +395,7 @@ If `./stageN/bin/rustc` gives an error about environment variables, that
 usually means something is quite wrong -- or you're trying to compile e.g.
 `rustc` or `std` or something that depends on environment variables. In
 the unlikely case that you actually need to invoke rustc in such a situation,
-you can tell the bootstrap shim to print all env variables by adding `-vvv` to your `x.py` command.
+you can tell the bootstrap shim to print all env variables by adding `-vvv` to your `x` command.
 
 Finally, bootstrap makes use of the [cc-rs crate] which has [its own
 method][env-vars] of configuring C compilers and C flags via environment
@@ -408,7 +408,7 @@ variables.
 
 In this part, we will investigate the build command's stdout in an action
 (similar, but more detailed and complete documentation compare to topic above).
-When you execute `x.py build --dry-run` command, the build output will be something
+When you execute `x build --dry-run` command, the build output will be something
 like the following:
 
 ```text
diff --git a/src/building/build-install-distribution-artifacts.md b/src/building/build-install-distribution-artifacts.md
index 4ec3f958a..df3037469 100644
--- a/src/building/build-install-distribution-artifacts.md
+++ b/src/building/build-install-distribution-artifacts.md
@@ -3,22 +3,22 @@
 You might want to build and package up the compiler for distribution.
 You’ll want to run this command to do it:
 
-   ```bash
-   ./x.py dist
-   ```
+```bash
+./x dist
+```
 
 # Install distribution artifacts
 
 If you’ve built a distribution artifact you might want to install it and
 test that it works on your target system. You’ll want to run this command:
 
-   ```bash
-   ./x.py install
-   ```
+```bash
+./x install
+```
 
    Note: If you are testing out a modification to a compiler, you
    might want to use it to compile some project.
-   Usually, you do not want to use `./x.py install` for testing.
+   Usually, you do not want to use `./x install` for testing.
    Rather, you should create a toolchain as discussed in
    [here][create-rustup-toolchain].
 
diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md
index 4e72bf994..948571ce8 100644
--- a/src/building/compiler-documenting.md
+++ b/src/building/compiler-documenting.md
@@ -10,13 +10,13 @@ like the standard library (std) or the compiler (rustc).
   as rustdoc is under active development:
 
   ```bash
-  ./x.py doc
+  ./x doc
   ```
 
   If you want to be sure the documentation looks the same as on CI:
 
   ```bash
-  ./x.py doc --stage 1
+  ./x doc --stage 1
   ```
 
   This ensures that (current) rustdoc gets built,
@@ -26,9 +26,9 @@ like the standard library (std) or the compiler (rustc).
   you can build just the documentation you want:
 
   ```bash
-  ./x.py doc src/doc/book
-  ./x.py doc src/doc/nomicon
-  ./x.py doc compiler library
+  ./x doc src/doc/book
+  ./x doc src/doc/nomicon
+  ./x doc compiler library
   ```
 
   See [the nightly docs index page](https://doc.rust-lang.org/nightly/) for a full list of books.
@@ -36,7 +36,7 @@ like the standard library (std) or the compiler (rustc).
 - Document internal rustc items
 
   Compiler documentation is not built by default.
-  To create it by default with `x.py doc`, modify `config.toml`:
+  To create it by default with `x doc`, modify `config.toml`:
 
   ```toml
   [build]
diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md
index 055cdca86..6b1b650ad 100644
--- a/src/building/how-to-build-and-run.md
+++ b/src/building/how-to-build-and-run.md
@@ -57,12 +57,37 @@ if you want to learn more about `x.py`, [read this chapter][bootstrap].
 
 [bootstrap]: ./bootstrapping.md
 
+Also, using `x` rather than `x.py` is recommended as:
+
+> `./x` is the most likely to work on every system (on Unix it runs the shell script
+> that does python version detection, on Windows it will probably run the
+> powershell script - certainly less likely to break than `./x.py` which often just
+> opens the file in an editor).[^1]
+
+(You can find the platform related scripts around the `x.py`, like `x.ps1`)
+
+Notice that this is not absolute, for instance, using Nushell in VSCode on Win10,
+typing `x` or `./x` still open the `x.py` in editor rather invoke the program :)
+
+In the rest of documents, we use `x` to represent the straightly usage of `x.py`, which
+means the following command:
+
+```bash
+./x check
+```
+
+could be replaced by:
+
+```bash
+./x.py check
+```
+
 ### Running `x.py`
 
 The `x.py` command can be run directly on most Unix systems in the following format:
 
 ```sh
-./x.py <subcommand> [flags]
+./x <subcommand> [flags]
 ```
 
 This is how the documentation and examples assume you are running `x.py`.
@@ -108,9 +133,14 @@ of a checkout. It also looks up the appropriate version of `python` to use.
 
 You can install it with `cargo install --path src/tools/x`.
 
+To clarify that this is another global installed binary util, which is
+similar to the fromer `x` declared in section [What is `x.py`](#what-is-xpy) but
+it works as an independent process to execute the `x.py` rather than calling the 
+shell to run the platform related scripts.
+
 ## Create a `config.toml`
 
-To start, run `./x.py setup` and select the `compiler` defaults. This will do some initialization
+To start, run `./x setup` and select the `compiler` defaults. This will do some initialization
 and create a `config.toml` for you with reasonable defaults. If you use a different default (which
 you'll likely want to do if you want to contribute to an area of rust other than the compiler, such
 as rustdoc), make sure to read information about that default (located in `src/bootstrap/defaults`)
@@ -120,30 +150,30 @@ Alternatively, you can write `config.toml` by hand. See `config.example.toml` fo
 settings and explanations of them. See `src/bootstrap/defaults` for common settings to change.
 
 If you have already built `rustc` and you change settings related to LLVM, then you may have to
-execute `rm -rf build` for subsequent configuration changes to take effect. Note that `./x.py
+execute `rm -rf build` for subsequent configuration changes to take effect. Note that `./x
 clean` will not cause a rebuild of LLVM.
 
-## Common `x.py` commands
+## Common `x` commands
 
-Here are the basic invocations of the `x.py` commands most commonly used when
+Here are the basic invocations of the `x` commands most commonly used when
 working on `rustc`, `std`, `rustdoc`, and other tools.
 
-| Command | When to use it |
-| --- | --- |
-| `./x.py check` | Quick check to see if most things compile; [rust-analyzer can run this automatically for you][rust-analyzer] |
-| `./x.py build` | Builds `rustc`, `std`, and `rustdoc` |
-| `./x.py test` | Runs all tests |
-| `./x.py fmt` | Formats all code |
+| Command     | When to use it                                                                                               |
+| ----------- | ------------------------------------------------------------------------------------------------------------ |
+| `./x check` | Quick check to see if most things compile; [rust-analyzer can run this automatically for you][rust-analyzer] |
+| `./x build` | Builds `rustc`, `std`, and `rustdoc`                                                                         |
+| `./x test`  | Runs all tests                                                                                               |
+| `./x fmt`   | Formats all code                                                                                             |
 
 As written, these commands are reasonable starting points. However, there are
 additional options and arguments for each of them that are worth learning for
-serious development work. In particular, `./x.py build` and `./x.py test`
+serious development work. In particular, `./x build` and `./x test`
 provide many ways to compile or test a subset of the code, which can save a lot
 of time.
 
-Also, note that `x.py` supports all kinds of path suffixes for `compiler`, `library`,
-and `src/tools` directories. So, you can simply run `x.py test tidy` instead of
-`x.py test src/tools/tidy`. Or, `x.py build std` instead of `x.py build library/std`.
+Also, note that `x` supports all kinds of path suffixes for `compiler`, `library`,
+and `src/tools` directories. So, you can simply run `x test tidy` instead of
+`x test src/tools/tidy`. Or, `x build std` instead of `x build library/std`.
 
 [rust-analyzer]: suggested.html#configuring-rust-analyzer-for-rustc
 
@@ -156,11 +186,11 @@ Note that building will require a relatively large amount of storage space.
 You may want to have upwards of 10 or 15 gigabytes available to build the compiler.
 
 Once you've created a `config.toml`, you are now ready to run
-`x.py`. There are a lot of options here, but let's start with what is
+`x`. There are a lot of options here, but let's start with what is
 probably the best "go to" command for building a local compiler:
 
 ```bash
-./x.py build library
+./x build library
 ```
 
 This may *look* like it only builds the standard library, but that is not the case.
@@ -183,10 +213,10 @@ see [the section on avoiding rebuilds for std][keep-stage].
 
 Sometimes you don't need a full build. When doing some kind of
 "type-based refactoring", like renaming a method, or changing the
-signature of some function, you can use `./x.py check` instead for a much faster build.
+signature of some function, you can use `./x check` instead for a much faster build.
 
 Note that this whole command just gives you a subset of the full `rustc`
-build. The **full** `rustc` build (what you get with `./x.py build
+build. The **full** `rustc` build (what you get with `./x build
 --stage 2 compiler/rustc`) has quite a few more steps:
 
 - Build `rustc` with the stage1 compiler.
@@ -203,10 +233,10 @@ the compiler unless you are planning to use a recently added nightly feature.
 Instead, you can just build using the bootstrap compiler.
 
 ```bash
-./x.py build --stage 0 library
+./x build --stage 0 library
 ```
 
-If you choose the `library` profile when running `x.py setup`, you can omit `--stage 0` (it's the
+If you choose the `library` profile when running `x setup`, you can omit `--stage 0` (it's the
 default).
 
 ## Creating a rustup toolchain
@@ -241,7 +271,7 @@ LLVM version: 11.0
 ```
 
 The rustup toolchain points to the specified toolchain compiled in your `build` directory,
-so the rustup toolchain will be updated whenever `x.py build` or `x.py test` are run for
+so the rustup toolchain will be updated whenever `x build` or `x test` are run for
 that toolchain/stage.
 
 **Note:** the toolchain we've built does not include `cargo`.  In this case, `rustup` will
@@ -256,25 +286,25 @@ custom toolchain for a project (e.g. via `rustup override set stage1`) you may
 want to build this component:
 
 ```bash
-./x.py build proc-macro-srv-cli
+./x build proc-macro-srv-cli
 ```
 
 ## Building targets for cross-compilation
 
 To produce a compiler that can cross-compile for other targets,
-pass any number of `target` flags to `x.py build`.
+pass any number of `target` flags to `x build`.
 For example, if your host platform is `x86_64-unknown-linux-gnu`
 and your cross-compilation target is `wasm32-wasi`, you can build with:
 
 ```bash
-./x.py build --target x86_64-unknown-linux-gnu --target wasm32-wasi
+./x build --target x86_64-unknown-linux-gnu --target wasm32-wasi
 ```
 
 Note that if you want the resulting compiler to be able to build crates that
 involve proc macros or build scripts, you must be sure to explicitly build target support for the
 host platform (in this case, `x86_64-unknown-linux-gnu`).
 
-If you want to always build for other targets without needing to pass flags to `x.py build`,
+If you want to always build for other targets without needing to pass flags to `x build`,
 you can configure this in the `[build]` section of your `config.toml` like so:
 
 ```toml
@@ -303,24 +333,24 @@ then once you have built your compiler you will be able to use it to cross-compi
 cargo +stage1 build --target wasm32-wasi
 ```
 
-## Other `x.py` commands
+## Other `x` commands
 
-Here are a few other useful `x.py` commands. We'll cover some of them in detail
+Here are a few other useful `x` commands. We'll cover some of them in detail
 in other sections:
 
 - Building things:
-  - `./x.py build` – builds everything using the stage 1 compiler,
+  - `./x build` – builds everything using the stage 1 compiler,
     not just up to `std`
-  - `./x.py build --stage 2` – builds everything with the stage 2 compiler including
+  - `./x build --stage 2` – builds everything with the stage 2 compiler including
     `rustdoc`
 - 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 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 tests/ui/const-generics/const-types.rs` - runs
-  the single test `const-types.rs` from the `ui` test suite
+  - `./x test library/std` – runs the unit tests and integration tests from `std`
+  - `./x test tests/ui` – runs the `ui` test suite
+  - `./x test tests/ui/const-generics` - runs all the tests in
+    the `const-generics/` subdirectory of the `ui` test suite
+  - `./x test tests/ui/const-generics/const-types.rs` - runs
+    the single test `const-types.rs` from the `ui` test suite
 
 ### Cleaning out build directories
 
@@ -330,8 +360,10 @@ you should file a bug as to what is going wrong. If you do need to clean
 everything up then you only need to run one command!
 
 ```bash
-./x.py clean
+./x clean
 ```
 
 `rm -rf build` works too, but then you have to rebuild LLVM, which can take
 a long time even on fast computers.
+
+[^1]: issue[#1707](https://github.com/rust-lang/rustc-dev-guide/issues/1707)
diff --git a/src/building/new-target.md b/src/building/new-target.md
index 629445be6..83973f2c9 100644
--- a/src/building/new-target.md
+++ b/src/building/new-target.md
@@ -10,7 +10,7 @@ relevant to your desired goal.
 
 For very new targets, you may need to use a different fork of LLVM
 than what is currently shipped with Rust. In that case, navigate to
-the `src/llvm-project` git submodule (you might need to run `./x.py
+the `src/llvm-project` git submodule (you might need to run `./x
 check` at least once so the submodule is updated), check out the
 appropriate commit for your fork, then commit that new submodule
 reference in the main Rust repository.
@@ -135,7 +135,7 @@ cross-compile `rustc`:
 
 ```
 DESTDIR=/path/to/install/in \
-./x.py install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \
+./x install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \
 compiler/rustc library/std
 ```
 
diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md
index 3dc2ea934..c511c7c81 100644
--- a/src/building/prerequisites.md
+++ b/src/building/prerequisites.md
@@ -20,7 +20,7 @@ recommend trying to build on a Raspberry Pi! We recommend the following.
 * 2+ cores. Having more cores really helps. 10 or 20 or more is not too many!
 
 Beefier machines will lead to much faster builds. If your machine is not very
-powerful, a common strategy is to only use `./x.py check` on your local machine
+powerful, a common strategy is to only use `./x check` on your local machine
 and let the CI build test your changes when you push to a PR branch.
 
 Building the compiler takes more than half an hour on my moderately powerful
diff --git a/src/building/suggested.md b/src/building/suggested.md
index 5c858f901..156546ffd 100644
--- a/src/building/suggested.md
+++ b/src/building/suggested.md
@@ -10,14 +10,14 @@ to make your life easier.
 CI will automatically fail your build if it doesn't pass `tidy`, our
 internal tool for ensuring code quality. If you'd like, you can install a
 [Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
-that will automatically run `./x.py test tidy` on each push, to ensure
-your code is up to par. If the hook fails then run `./x.py test tidy --bless`
+that will automatically run `./x test tidy` on each push, to ensure
+your code is up to par. If the hook fails then run `./x test tidy --bless`
 and commit the changes. If you decide later that the pre-push behavior is
 undesirable, you can delete the `pre-push` file in `.git/hooks`.
 
 A prebuilt git hook lives at [`src/etc/pre-push.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-push.sh) which can be copied into your `.git/hooks` folder as `pre-push` (without the `.sh` extension!).
 
-You can also install the hook as a step of running `./x.py setup`!
+You can also install the hook as a step of running `./x setup`!
 
 ## Configuring `rust-analyzer` for `rustc`
 
@@ -26,22 +26,22 @@ You can also install the hook as a step of running `./x.py setup`!
 `rust-analyzer` can help you check and format your code whenever you save
 a file. By default, `rust-analyzer` runs the `cargo check` and `rustfmt`
 commands, but you can override these commands to use more adapted versions
-of these tools when hacking on `rustc`. For example, `x.py setup vscode` will prompt
+of these tools when hacking on `rustc`. For example, `x setup vscode` will prompt
 you to create a `.vscode/settings.json` file which will configure Visual Studio code.
-This will ask `rust-analyzer` to use `./x.py check` to check the sources, and the
+This will ask `rust-analyzer` to use `./x check` to check the sources, and the
 stage 0 rustfmt to format them.
 The recommended `rust-analyzer` settings live at [`src/etc/rust_analyzer_settings.json`].
 
-If you have enough free disk space and you would like to be able to run `x.py` commands while
+If you have enough free disk space and you would like to be able to run `x` commands while
 rust-analyzer runs in the background, you can also add `--build-dir build-rust-analyzer` to the
-`overrideCommand` to avoid x.py locking.
+`overrideCommand` to avoid x locking.
 
 If you're running `coc.nvim`, you can use `:CocLocalConfig` to create a
 `.vim/coc-settings.json` and copy the settings from [`src/etc/rust_analyzer_settings.json`].
 
 [`src/etc/rust_analyzer_settings.json`]: https://github.com/rust-lang/rust/blob/master/src/etc/rust_analyzer_settings.json
 
-If running `./x.py check` on save is inconvenient, in VS Code you can use a [Build
+If running `./x check` on save is inconvenient, in VS Code you can use a [Build
 Task] instead:
 
 ```JSON
@@ -50,8 +50,8 @@ Task] instead:
     "version": "2.0.0",
     "tasks": [
         {
-            "label": "./x.py check",
-            "command": "./x.py check",
+            "label": "./x check",
+            "command": "./x check",
             "type": "shell",
             "problemMatcher": "$rustc",
             "presentation": { "clear": true },
@@ -73,9 +73,9 @@ Rust-Analyzer to already be configured with Neovim. Steps for this can be
 [found here](https://rust-analyzer.github.io/manual.html#nvim-lsp).
 
 1. First install the plugin. This can be done by following the steps in the README.
-2. Run `x.py setup`, which will have a prompt for it to create a `.vscode/settings.json` file. 
-`neoconf` is able to read and update Rust-Analyzer settings automatically when the project is 
-opened when this file is detected.
+2. Run `x setup`, which will have a prompt for it to create a `.vscode/settings.json` file.
+   `neoconf` is able to read and update Rust-Analyzer settings automatically when the project is
+   opened when this file is detected.
 
 If you're running `coc.nvim`, you can use `:CocLocalConfig` to create a
 `.vim/coc-settings.json` and copy the settings from 
@@ -94,11 +94,11 @@ follow the same instructions as above.
 
 ## Check, check, and check again
 
-When doing simple refactorings, it can be useful to run `./x.py check`
+When doing simple refactorings, it can be useful to run `./x check`
 continuously. If you set up `rust-analyzer` as described above, this will
 be done for you every time you save a file. Here you are just checking that
 the compiler can **build**, but often that is all you need (e.g., when renaming a
-method). You can then run `./x.py build` when you actually need to
+method). You can then run `./x build` when you actually need to
 run tests.
 
 In fact, it is sometimes useful to put off tests even when you are not
@@ -141,11 +141,11 @@ directories you have [setup a worktree for]. You may need to use the pinned
 nightly version from `src/stage0.json`, but often the normal `nightly` channel
 will work.
 
-**Note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses,
+**Note** see [the section on vscode] for how to configure it with this real rustfmt `x` uses,
 and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler
 
 **Note** This does _not_ allow you to build `rustc` with cargo directly. You
-still have to use `x.py` to work on the compiler or standard library, this just
+still have to use `x` to work on the compiler or standard library, this just
 lets you use `cargo fmt`.
 
 [installing a nightly toolchain]: https://rust-lang.github.io/rustup/concepts/channels.html?highlight=nightl#working-with-nightly-rust
@@ -166,13 +166,13 @@ don't work (but that is easily detected and fixed).
 
 The sequence of commands you want is as follows:
 
-- Initial build: `./x.py build library`
+- Initial build: `./x build library`
   - As [documented previously], this will build a functional
     stage1 compiler as part of running all stage0 commands (which include
     building a `std` compatible with the stage1 compiler) as well as the
     first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1)
     builds std".
-- Subsequent builds: `./x.py build library --keep-stage 1`
+- Subsequent builds: `./x build library --keep-stage 1`
   - Note that we added the `--keep-stage 1` flag here
 
 [documented previously]: ./how-to-build-and-run.md#building-the-compiler
@@ -194,8 +194,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 tests/ui`
-- Subsequent test run: `./x.py test tests/ui --keep-stage 1`
+- Initial test run: `./x test tests/ui`
+- Subsequent test run: `./x test tests/ui --keep-stage 1`
 
 ## Using incremental compilation
 
@@ -203,7 +203,7 @@ You can further enable the `--incremental` flag to save additional
 time in subsequent rebuilds:
 
 ```bash
-./x.py test tests/ui --incremental --test-args issue-1234
+./x test tests/ui --incremental --test-args issue-1234
 ```
 
 If you don't want to include the flag with every command, you can
diff --git a/src/contributing.md b/src/contributing.md
index 6ed62b0e0..6e81ce1f9 100644
--- a/src/contributing.md
+++ b/src/contributing.md
@@ -200,7 +200,7 @@ of the status of a particular pull request.
 Rust has plenty of CI capacity, and you should never have to worry about wasting
 computational resources each time you push a change. It is also perfectly fine
 (and even encouraged!) to use the CI to test your changes if it can help your
-productivity. In particular, we don't recommend running the full `./x.py test` suite locally,
+productivity. In particular, we don't recommend running the full `./x test` suite locally,
 since it takes a very long time to execute.
 
 ### r+
@@ -241,7 +241,7 @@ branch, `master` will be the right choice (it's also the default).
 
 Make sure your pull request is in compliance with Rust's style guidelines by running
 
-    $ ./x.py test tidy --bless
+    $ ./x test tidy --bless
 
 We recommend to make this check before every pull request (and every new commit
 in a pull request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
diff --git a/src/conventions.md b/src/conventions.md
index 521aeb4a5..1c963c669 100644
--- a/src/conventions.md
+++ b/src/conventions.md
@@ -13,11 +13,11 @@ However, for now we don't use stable `rustfmt`; we use a pinned version with a
 special config, so this may result in different style from normal [`rustfmt`].
 Therefore, formatting this repository using `cargo fmt` is not recommended.
 
-Instead, formatting should be done using `./x.py fmt`. It's a good habit to run
-`./x.py fmt` before every commit, as this reduces conflicts later.
+Instead, formatting should be done using `./x fmt`. It's a good habit to run
+`./x fmt` before every commit, as this reduces conflicts later.
 
 Formatting is checked by the `tidy` script. It runs automatically when you do
-`./x.py test` and can be run in isolation with `./x.py fmt --check`.
+`./x test` and can be run in isolation with `./x fmt --check`.
 
 If you want to use format-on-save in your editor, the pinned version of
 `rustfmt` is built under `build/<target>/stage0/bin/rustfmt`. You'll have to
@@ -126,7 +126,7 @@ dramatically (versus adding to it) in a later commit, that
 
 **Format liberally.** While only the final commit of a PR must be correctly
 formatted, it is both easier to review and less noisy to format each commit
-individually using `./x.py fmt`.
+individually using `./x fmt`.
 
 **No merges.** We do not allow merge commits into our history, other
 than those by bors. If you get a merge conflict, rebase instead via a
diff --git a/src/diagnostics/error-codes.md b/src/diagnostics/error-codes.md
index 2dbdb53fe..7cdf5ebca 100644
--- a/src/diagnostics/error-codes.md
+++ b/src/diagnostics/error-codes.md
@@ -37,7 +37,7 @@ To create a new error, you first need to find the next available
 code. You can find it with `tidy`:
 
 ```
-./x.py test tidy
+./x test tidy
 ```
 
 This will invoke the tidy script, which generally checks that your code obeys
diff --git a/src/git.md b/src/git.md
index 34f2f101e..9085a8313 100644
--- a/src/git.md
+++ b/src/git.md
@@ -10,7 +10,7 @@ can be incorporated into the compiler.
 
 The goal of this page is to cover some of the more common questions and
 problems new contributors face. Although some Git basics will be covered here,
-if you  find that this is still a little too fast for you, it might make sense
+if you find that this is still a little too fast for you, it might make sense
 to first read some introductions to Git, such as the Beginner and Getting
 started sections of [this tutorial from Atlassian][atlassian-git]. GitHub also
 provides [documentation] and [guides] for beginners, or you can consult the
@@ -139,7 +139,7 @@ You might also notice conflicts in the web UI:
 ![conflict in src/tools/cargo](./img/submodule-conflicts.png)
 
 The most common cause is that you rebased after a change and ran `git add .` without first running
-`x.py` to update the submodules.  Alternatively, you might have run `cargo fmt` instead of `x fmt`
+`x` to update the submodules.  Alternatively, you might have run `cargo fmt` instead of `x fmt`
 and modified files in a submodule, then committed the changes.
 
 To fix it, do the following things:
@@ -239,7 +239,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
 ```
 
 These changes are not changes to files: they are changes to submodules (more on this
-[later](#git-submodules)). To get rid of those, run `./x.py --help`, which will automatically update
+[later](#git-submodules)). To get rid of those, run `./x --help`, which will automatically update
 the submodules.
 
 Some submodules are not actually needed; for example, `src/llvm-project` doesn't need to be checked
@@ -248,7 +248,7 @@ out if you're using `download-ci-llvm`.  To avoid having to keep fetching its hi
 
 Note that, as of <!-- date-check --> Aug 2022,
 there is a [bug][#77620] if you use worktrees,
-submodules, and `x.py` in a commit hook.
+submodules, and `x` in a commit hook.
 If you run into an error like the following,
 it's not anything you did wrong:
 
@@ -314,7 +314,7 @@ Generally, resolving the conflict consists of two steps: First, fix the
 particular conflict. Edit the file to make the changes you want and remove the
 `<<<<<<<`, `=======` and `>>>>>>>` lines in the process. Second, check the
 surrounding code. If there was a conflict, its likely there are some logical
-errors lying around too! It's a good idea to run `x.py check` here to make sure
+errors lying around too! It's a good idea to run `x check` here to make sure
 there are no glaring errors.
 
 Once you're all done fixing the conflicts, you need to stage the files that had
@@ -558,7 +558,7 @@ commit, which doesn't change unless modified manually. If you use `git checkout
 in the `llvm-project` directory and go back to the `rust` directory, you can stage this
 change like any other, e.g. by running `git add src/llvm-project`. (Note that if
 you *don't* stage the change to commit, then you run the risk that running
-`x.py` will just undo your change by switching back to the previous commit when
+`x` will just undo your change by switching back to the previous commit when
 it automatically "updates" the submodules.)
 
 This version selection is usually done by the maintainers of the project, and
diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md
index 447b621da..c7f2aa000 100644
--- a/src/implementing_new_features.md
+++ b/src/implementing_new_features.md
@@ -177,8 +177,8 @@ a new unstable feature:
 
 1. Add a test to ensure the feature cannot be used without
    a feature gate, by creating `tests/ui/feature-gates/feature-gate-$feature_name.rs`.
-   You can generate the corresponding `.stderr` file by running `./x.py test tests/ui/feature-gates/
-   --bless`.
+   You can generate the corresponding `.stderr` file by running `./x test 
+tests/ui/feature-gates/ --bless`.
 
 1. Add a section to the unstable book, in
    `src/doc/unstable-book/src/language-features/$feature_name.md`.
diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md
index 99baa8821..c90c9f75f 100644
--- a/src/llvm-coverage-instrumentation.md
+++ b/src/llvm-coverage-instrumentation.md
@@ -292,8 +292,8 @@ Expected results for both the `mir-opt` tests and the `coverage*` tests under
 `run-make-fulldeps` can be refreshed by running:
 
 ```shell
-$ ./x.py test mir-opt --bless
-$ ./x.py test tests/run-make-fulldeps/coverage --bless
+$ ./x test mir-opt --bless
+$ ./x test tests/run-make-fulldeps/coverage --bless
 ```
 
 [mir-opt-test]: https://github.com/rust-lang/rust/blob/master/tests/mir-opt/instrument_coverage.rs
diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md
index 261825d4f..16cf2035b 100644
--- a/src/mir/optimizations.md
+++ b/src/mir/optimizations.md
@@ -34,7 +34,7 @@ optimizes it, and returns the improved MIR.
    `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 tests/mir-opt/<your-test>.rs` to generate a MIR
+2. Run `./x 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 tests/mir-opt/<your-test>.rs` to regenerate the
+5. Rerun `./x 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 tests/ui` to see if your optimization broke anything.
+6. Run `./x 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.
diff --git a/src/profiling.md b/src/profiling.md
index e1666e237..df987e00a 100644
--- a/src/profiling.md
+++ b/src/profiling.md
@@ -19,7 +19,7 @@ Depending on what you're trying to measure, there are several different approach
 - If you want a nice visual representation of the compile times of your crate graph,
   you can use [cargo's `--timings` flag](https://doc.rust-lang.org/nightly/cargo/reference/timings.html),
   e.g. `cargo build --timings`.
-  You can use this flag on the compiler itself with `CARGOFLAGS="--timings" ./x.py build`
+  You can use this flag on the compiler itself with `CARGOFLAGS="--timings" ./x build`
 
 - If you want to profile memory usage, you can use various tools depending on what operating system
   you are using.
@@ -41,11 +41,11 @@ extension in LLVM bitcode format.
 Example usage:
 ```
 cargo install cargo-llvm-lines
-# On a normal crate you could now run `cargo llvm-lines`, but `x.py` isn't normal :P
+# On a normal crate you could now run `cargo llvm-lines`, but `x` isn't normal :P
 
 # Do a clean before every run, to not mix in the results from previous runs.
-./x.py clean
-env RUSTFLAGS=-Csave-temps ./x.py build --stage 0 compiler/rustc
+./x clean
+env RUSTFLAGS=-Csave-temps ./x build --stage 0 compiler/rustc
 
 # Single crate, e.g., rustc_middle. (Relies on the glob support of your shell.)
 # Convert unoptimized LLVM bitcode into a human readable LLVM assembly accepted by cargo-llvm-lines.
@@ -85,7 +85,7 @@ Example output for the compiler:
     326903 (0.7%)      642 (0.0%)  rustc_query_system::query::plumbing::try_execute_query
 ```
 
-Since this doesn't seem to work with incremental compilation or `./x.py check`,
+Since this doesn't seem to work with incremental compilation or `./x check`,
 you will be compiling rustc _a lot_.
 I recommend changing a few settings in `config.toml` to make it bearable:
 ```
diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md
index c9bd88ecd..1ea5c1ed2 100644
--- a/src/profiling/with_perf.md
+++ b/src/profiling/with_perf.md
@@ -10,7 +10,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or
   - `debuginfo-level = 1` - enables line debuginfo
   - `jemalloc = false` - lets you do memory use profiling with valgrind
   - leave everything else the defaults
-- Run `./x.py build` to get a full build
+- Run `./x build` to get a full build
 - Make a rustup toolchain pointing to that result
   - see [the "build and run" section for instructions][b-a-r]
 
diff --git a/src/profiling/wpa_profiling.md b/src/profiling/wpa_profiling.md
index e7cf9418c..a800c5717 100644
--- a/src/profiling/wpa_profiling.md
+++ b/src/profiling/wpa_profiling.md
@@ -47,11 +47,11 @@ we'll need to build a stage 1 compiler and then a stage 2 compiler ourselves.
 To do this, make sure you have set `debuginfo-level = 1` in your `config.toml` file. This tells
 rustc to generate debug information which includes stack frames when bootstrapping.
 
-Now you can build the stage 1 compiler: `python x.py build --stage 1 -i library` or however
+Now you can build the stage 1 compiler: `x build --stage 1 -i library` or however
 else you want to build the stage 1 compiler.
 
 Now that the stage 1 compiler is built, we can record the stage 2 build. Go back to WPR, click the
-"start" button and build the stage 2 compiler (e.g., `python x build --stage=2 -i library`).
+"start" button and build the stage 2 compiler (e.g., `x build --stage=2 -i library`).
 When this process finishes, stop the recording.
 
 Click the Save button and once that process is complete, click the "Open in WPA" button which
diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md
index c626eb60f..e78c4bb25 100644
--- a/src/rustdoc-internals.md
+++ b/src/rustdoc-internals.md
@@ -281,7 +281,7 @@ server. To test these features locally, you can run a local HTTP server, like
 this:
 
 ```bash
-$ ./x.py doc library
+$ ./x doc library
 # The documentation has been generated into `build/[YOUR ARCH]/doc`.
 $ python3 -m http.server -d build/[YOUR ARCH]/doc
 ```
diff --git a/src/rustdoc.md b/src/rustdoc.md
index cbe5e8b1f..02da8be81 100644
--- a/src/rustdoc.md
+++ b/src/rustdoc.md
@@ -41,24 +41,24 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
 
 ## Cheat sheet
 
-* Run `./x.py setup tools` before getting started. This will configure `x.py`
+* Run `./x setup tools` before getting started. This will configure `x`
   with nice settings for developing rustdoc and other tools, including
   downloading a copy of rustc rather than building it.
-* Use `./x.py check src/tools/rustdoc` to quickly check for compile errors.
-* Use `./x.py build` to make a usable
+* Use `./x check src/tools/rustdoc` to quickly check for compile errors.
+* Use `./x build` to make a usable
   rustdoc you can run on other projects.
   * Add `library/test` to be able to use `rustdoc --test`.
   * Run `rustup toolchain link stage2 build/host/stage2` to add a
     custom toolchain called `stage2` to your rustup environment. After
     running that, `cargo +stage2 doc` in any directory will build with
     your locally-compiled rustdoc.
-* Use `./x.py doc library` to use this rustdoc to generate the
+* Use `./x doc library` to use this rustdoc to generate the
   standard library docs.
   * The completed docs will be available in `build/host/doc` (under `core`, `alloc`, and `std`).
   * 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 tests/rustdoc*` to run the tests using a stage1
+* Use `./x test tests/rustdoc*` to run the tests using a stage1
   rustdoc.
   * See [Rustdoc internals] for more information about tests.
 
diff --git a/src/sanitizers.md b/src/sanitizers.md
index 21b07ec99..27d40a11a 100644
--- a/src/sanitizers.md
+++ b/src/sanitizers.md
@@ -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 tests/ui/sanitize/` to verify.
+4. Run tests `./x 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.
 
diff --git a/src/tests/adding.md b/src/tests/adding.md
index 632614539..fc0c4937e 100644
--- a/src/tests/adding.md
+++ b/src/tests/adding.md
@@ -84,7 +84,7 @@ The next step is to create the expected output from the compiler.
 This can be done with the `--bless` option:
 
 ```sh
-./x.py test tests/ui/async-await/await-without-async.rs --bless
+./x test tests/ui/async-await/await-without-async.rs --bless
 ```
 
 This will build the compiler (if it hasn't already been built), compile the
@@ -118,7 +118,7 @@ annotations](ui.md#error-annotations) section).
 Save that, and run the test again:
 
 ```sh
-./x.py test tests/ui/async-await/await-without-async.rs
+./x test tests/ui/async-await/await-without-async.rs
 ```
 
 It should now pass, yay!
@@ -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 tests/ui
+./x test tests/ui
 ```
 
 If other tests start failing, you may need to investigate what has changed
diff --git a/src/tests/ci.md b/src/tests/ci.md
index cca4973cb..bfdc2a45a 100644
--- a/src/tests/ci.md
+++ b/src/tests/ci.md
@@ -6,7 +6,7 @@
 When a Pull Request is opened on GitHub, [GitHub Actions] will automatically
 launch a build that will run all tests on some configurations
 (x86_64-gnu-llvm-13 linux, x86_64-gnu-tools linux, and mingw-check linux).
-In essence, each runs `./x.py test` with various different options.
+In essence, each runs `./x test` with various different options.
 
 The integration bot [bors] is used for coordinating merges to the master branch.
 When a PR is approved, it goes into a [queue] where merges are tested one at a
@@ -54,8 +54,8 @@ the other jobs.
 The comment at the top of `ci.yml` will tell you to run this command:
 
 ```sh
-./x.py run src/tools/expand-yaml-anchors
-````
+./x run src/tools/expand-yaml-anchors
+```
 
 This will generate the true [`.github/workflows/ci.yml`] which is what GitHub
 Actions uses.
diff --git a/src/tests/compiletest.md b/src/tests/compiletest.md
index 4b685aa20..f73d2435a 100644
--- a/src/tests/compiletest.md
+++ b/src/tests/compiletest.md
@@ -330,7 +330,7 @@ set a baseline for optimizations:
 
 The test should be annotated with `// EMIT_MIR` comments that specify files that
 will contain the expected MIR output.
-You can use `x.py test --bless` to create the initial expected files.
+You can use `x test --bless` to create the initial expected files.
 
 There are several forms the `EMIT_MIR` comment can take:
 
@@ -503,10 +503,9 @@ currently only apply to the test as a whole, not to particular
 revisions. The only headers that are intended to really work when
 customized to a revision are error patterns and compiler flags.
 
-
 ## Compare modes
 
-Compiletest can be run in different modes, called *compare modes*, which can
+Compiletest can be run in different modes, called _compare modes_, which can
 be used to compare the behavior of all tests with different compiler flags
 enabled.
 This can help highlight what differences might appear with certain flags, and
@@ -516,7 +515,7 @@ To run the tests in a different mode, you need to pass the `--compare-mode`
 CLI flag:
 
 ```bash
-./x.py test tests/ui --compare-mode=chalk
+./x test tests/ui --compare-mode=chalk
 ```
 
 The possible compare modes are:
@@ -537,5 +536,5 @@ following settings:
   enabling split-DWARF.
 
 Note that compare modes are separate to [revisions](#revisions).
-All revisions are tested when running `./x.py test tests/ui`, however
+All revisions are tested when running `./x test tests/ui`, however
 compare-modes must be manually run individually via the `--compare-mode` flag.
diff --git a/src/tests/docker.md b/src/tests/docker.md
index 0d9e0a492..31e3825f5 100644
--- a/src/tests/docker.md
+++ b/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 tests/ui` to just run UI tests.
+example, you can run `../x 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.
diff --git a/src/tests/headers.md b/src/tests/headers.md
index 682c96b44..2034fba5e 100644
--- a/src/tests/headers.md
+++ b/src/tests/headers.md
@@ -145,7 +145,7 @@ The following header commands will check rustc build settings and target setting
   (AddressSanitizer, hardware-assisted AddressSanitizer, LeakSanitizer,
   MemorySanitizer or ThreadSanitizer respectively)
 * `needs-run-enabled` — ignores if it is a test that gets executed, and
-  running has been disabled. Running tests can be disabled with the `x.py test
+  running has been disabled. Running tests can be disabled with the `x test
   --run=never` flag, or running on fuchsia.
 * `needs-unwind` — ignores if the target does not support unwinding
 * `needs-rust-lld` — ignores if the rust lld support is not enabled
diff --git a/src/tests/intro.md b/src/tests/intro.md
index adc5d58ec..aad77e255 100644
--- a/src/tests/intro.md
+++ b/src/tests/intro.md
@@ -3,14 +3,14 @@
 <!-- toc -->
 
 The Rust project runs a wide variety of different tests, orchestrated by
-the build system (`./x.py test`).
+the build system (`./x test`).
 This section gives a brief overview of the different testing tools.
 Subsequent chapters dive into [running tests](running.md) and [adding new tests](adding.md).
 
 ## Kinds of tests
 
 There are several kinds of tests to exercise things in the Rust distribution.
-Almost all of them are driven by `./x.py test`, with some exceptions noted below.
+Almost all of them are driven by `./x test`, with some exceptions noted below.
 
 ### Compiletest
 
@@ -19,7 +19,7 @@ It supports running different styles of tests, called *test suites*.
 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 tests/ui`
+> Example: `./x test tests/ui`
 
 [compiletest]: compiletest.md
 [`tests`]: https://github.com/rust-lang/rust/tree/master/tests
@@ -29,15 +29,15 @@ The [Compiletest chapter][compiletest] goes into detail on how to use this tool.
 The standard library and many of the compiler packages include typical Rust `#[test]`
 unit tests, integration tests, and documentation tests.
 You can pass a path to `x.py` to almost any package in the `library` or `compiler` directory,
-and `x.py` will essentially run `cargo test` on that package.
+and `x` will essentially run `cargo test` on that package.
 
 Examples:
 
-| Command | Description |
-|---------|-------------|
-| `./x.py test library/std` | Runs tests on `std` only |
-| `./x.py test library/core` | Runs tests on `core` only |
-| `./x.py test compiler/rustc_data_structures` | Runs tests on `rustc_data_structures` |
+| Command                                   | Description                           |
+| ----------------------------------------- | ------------------------------------- |
+| `./x test library/std`                    | Runs tests on `std` only              |
+| `./x test library/core`                   | Runs tests on `core` only             |
+| `./x test compiler/rustc_data_structures` | Runs tests on `rustc_data_structures` |
 
 The standard library relies very heavily on documentation tests to cover its functionality.
 However, unit tests and integration tests can also be used as needed.
@@ -58,7 +58,7 @@ then changing or adding a test would cause the crate you are working on to be re
 If you were working on something like `core`,
 then that would require recompiling the entire standard library, and the entirety of `rustc`.
 
-`./x.py test` includes some CLI options for controlling the behavior with these tests:
+`./x test` includes some CLI options for controlling the behavior with these tests:
 
 * `--doc` — Only runs documentation tests in the package.
 * `--no-doc` — Run all tests *except* documentation tests.
@@ -71,7 +71,7 @@ Tidy is a custom tool used for validating source code style and formatting conve
 such as rejecting long lines.
 There is more information in the [section on coding conventions](../conventions.md#formatting).
 
-> Example: `./x.py test tidy`
+> Example: `./x test tidy`
 
 ### Formatting
 
@@ -80,28 +80,28 @@ The formatting check is automatically run by the Tidy tool mentioned above.
 
 Examples:
 
-| Command | Description |
-|---------|-------------|
-| `./x.py fmt --check` | Checks formatting and exits with an error if formatting is needed. |
-| `./x.py fmt` | Runs rustfmt across the entire codebase. |
-| `./x.py test tidy --bless` | First runs rustfmt to format the codebase, then runs tidy checks. |
+| Command                 | Description                                                        |
+| ----------------------- | ------------------------------------------------------------------ |
+| `./x fmt --check`       | Checks formatting and exits with an error if formatting is needed. |
+| `./x fmt`               | Runs rustfmt across the entire codebase.                           |
+| `./x test tidy --bless` | First runs rustfmt to format the codebase, then runs tidy checks.  |
 
 ### Book documentation tests
 
 All of the books that are published have their own tests,
 primarily for validating that the Rust code examples pass.
 Under the hood, these are essentially using `rustdoc --test` on the markdown files.
-The tests can be run by passing a path to a book to `./x.py test`.
+The tests can be run by passing a path to a book to `./x test`.
 
-> Example: `./x.py test src/doc/book`
+> Example: `./x test src/doc/book`
 
 ### Documentation link checker
 
 Links across all documentation is validated with a link checker tool.
 
-> Example: `./x.py test src/tools/linkchecker`
+> Example: `./x test src/tools/linkchecker`
 
-> Example: `./x.py test linkchecker`
+> Example: `./x test linkchecker`
 
 This requires building all of the documentation, which might take a while.
 
@@ -110,7 +110,7 @@ This requires building all of the documentation, which might take a while.
 `distcheck` verifies that the source distribution tarball created by the build system
 will unpack, build, and run all tests.
 
-> Example: `./x.py test distcheck`
+> Example: `./x test distcheck`
 
 ### Tool tests
 
@@ -119,9 +119,9 @@ This includes things such as cargo, clippy, rustfmt, miri, bootstrap
 (testing the Rust build system itself), etc.
 
 Most of the tools are located in the [`src/tools`] directory.
-To run the tool's tests, just pass its path to `./x.py test`.
+To run the tool's tests, just pass its path to `./x test`.
 
-> Example: `./x.py test src/tools/cargo`
+> Example: `./x test src/tools/cargo`
 
 Usually these tools involve running `cargo test` within the tool's directory.
 
@@ -139,7 +139,7 @@ More information can be found in the [toolstate documentation].
 (such as `servo`, `ripgrep`, `tokei`, etc.).
 This ensures there aren't any significant regressions.
 
-> Example: `./x.py test src/tools/cargotest`
+> Example: `./x test src/tools/cargotest`
 
 ### Crater
 
diff --git a/src/tests/running.md b/src/tests/running.md
index 0a3de6f8b..6bc794ca9 100644
--- a/src/tests/running.md
+++ b/src/tests/running.md
@@ -2,11 +2,11 @@
 
 <!-- toc -->
 
-You can run the tests using `x.py`. The most basic command – which
+You can run the tests using `x`. The most basic command – which
 you will almost never want to use! – is as follows:
 
 ```bash
-./x.py test
+./x test
 ```
 
 This will build the stage 1 compiler and then run the whole test
@@ -37,7 +37,7 @@ modifying rustc to see if things are generally working correctly would be the
 following:
 
 ```bash
-./x.py test tests/ui
+./x test tests/ui
 ```
 
 This will run the `ui` test suite. Of course, the choice
@@ -46,32 +46,32 @@ doing. For example, if you are hacking on debuginfo, you may be better off
 with the debuginfo test suite:
 
 ```bash
-./x.py test tests/debuginfo
+./x 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`:
+given test suite, you can pass that directory to `./x test`:
 
 ```bash
-./x.py test tests/ui/const-generics
+./x test tests/ui/const-generics
 ```
 
 Likewise, you can test a single file by passing its path:
 
 ```bash
-./x.py test tests/ui/const-generics/const-test.rs
+./x test tests/ui/const-generics/const-test.rs
 ```
 
 ### Run only the tidy script
 
 ```bash
-./x.py test tidy
+./x test tidy
 ```
 
 ### Run tests on the standard library
 
 ```bash
-./x.py test --stage 0 library/std
+./x test --stage 0 library/std
 ```
 
 Note that this only runs tests on `std`; if you want to test `core` or other crates,
@@ -80,13 +80,13 @@ you have to specify those explicitly.
 ### Run the tidy script and tests on the standard library
 
 ```bash
-./x.py test --stage 0 tidy library/std
+./x test --stage 0 tidy library/std
 ```
 
 ### Run tests on the standard library using a stage 1 compiler
 
 ```bash
-./x.py test --stage 1 library/std
+./x test --stage 1 library/std
 ```
 
 By listing which test suites you want to run you avoid having to run
@@ -99,7 +99,7 @@ there are some limitations.
 ### Run all tests using a stage 2 compiler
 
 ```bash
-./x.py test --stage 2
+./x test --stage 2
 ```
 You almost never need to do this; CI will run these tests for you.
 
@@ -108,13 +108,13 @@ You almost never need to do this; CI will run these tests for you.
 You may want to run unit tests on a specific file with following:
 
 ```bash
-./x.py test compiler/rustc_data_structures/src/thin_vec/tests.rs
+./x test compiler/rustc_data_structures/src/thin_vec/tests.rs
 ```
 
 But unfortunately, it's impossible. You should invoke following instead:
 
 ```bash
-./x.py test compiler/rustc_data_structures/ --test-args thin_vec
+./x test compiler/rustc_data_structures/ --test-args thin_vec
 ```
 
 ## Running an individual test
@@ -122,10 +122,10 @@ But unfortunately, it's impossible. You should invoke following instead:
 Another common thing that people want to do is to run an **individual
 test**, often the test they are trying to fix. As mentioned earlier,
 you may pass the full file path to achieve this, or alternatively one
-may invoke `x.py` with the `--test-args` option:
+may invoke `x` with the `--test-args` option:
 
 ```bash
-./x.py test tests/ui --test-args issue-1234
+./x test tests/ui --test-args issue-1234
 ```
 
 Under the hood, the test runner invokes the standard Rust test runner
@@ -140,7 +140,7 @@ making a new test, you can pass `--bless` to the test subcommand. E.g.
 if some tests in `tests/ui` are failing, you can run
 
 ```text
-./x.py test tests/ui --bless
+./x test tests/ui --bless
 ```
 
 to automatically adjust the `.stderr`, `.stdout` or `.fixed` files of
@@ -168,7 +168,7 @@ exists in the test file. For example, you can run all the tests in
 `tests/ui` as `check-pass`:
 
 ```bash
-./x.py test tests/ui --pass check
+./x test tests/ui --pass check
 ```
 
 By passing `--pass $mode`, you can reduce the testing time. For each
@@ -184,7 +184,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 tests/ui --compare-mode=polonius
+./x test tests/ui --compare-mode=polonius
 ```
 
 See [Compare modes](compiletest.md#compare-modes) for more details.
@@ -217,7 +217,7 @@ execution* so be careful where it is used.
 To do this, first build `remote-test-server` for the remote
 machine, e.g. for RISC-V
 ```sh
-./x.py build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu
+./x build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu
 ```
 
 The binary will be created at
@@ -247,11 +247,11 @@ pong
 ```
 
 To run tests using the remote runner, set the `TEST_DEVICE_ADDR` environment
-variable then use `x.py` as usual. For example, to run `ui` tests for a RISC-V
+variable then use `x` 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 tests/ui --target riscv64gc-unknown-linux-gnu
+./x test tests/ui --target riscv64gc-unknown-linux-gnu
 ```
 
 If `remote-test-server` was run with the verbose flag, output on the test machine
@@ -273,7 +273,7 @@ run "/tmp/work/test1018/a"
 [...]
 ```
 
-Tests are built on the machine running `x.py` not on the remote machine. Tests
+Tests are built on the machine running `x` not on the remote machine. Tests
 which fail to build unexpectedly (or `ui` tests producing incorrect build
 output) may fail without ever running on the remote machine.
 
diff --git a/src/tests/ui.md b/src/tests/ui.md
index d94d8cc4e..b6409bbee 100644
--- a/src/tests/ui.md
+++ b/src/tests/ui.md
@@ -390,7 +390,7 @@ Tests with the `*-pass` headers can be overridden with the `--pass`
 command-line option:
 
 ```sh
-./x.py test tests/ui --pass check
+./x test tests/ui --pass check
 ```
 
 The `--pass` option only affects UI tests.
@@ -485,7 +485,7 @@ Then, it applies the suggestion and compares against `.fixed` (they must match).
 Finally, the fixed source is compiled, and this compilation is required to succeed.
 
 Usually when creating a rustfix test you will generate the `.fixed` file
-automatically with the `x.py test --bless` option.
+automatically with the `x test --bless` option.
 
 The `run-rustfix` header will cause *all* suggestions to be applied, even
 if they are not [`MachineApplicable`](../diagnostics.md#suggestions).
@@ -515,7 +515,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 tests/ui --compare-mode=polonius --bless
+./x test tests/ui --compare-mode=polonius --bless
 ```
 
 Currently none of the compare modes are checked in CI for UI tests.