Unify x.py usage

src/backend/updating-llvm.md

@@ -102,7 +102,7 @@ through each in detail.
    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.py setup`
    download LLVM from CI instead of building it from source. You should
    disable this temporarily to make sure your changes are being used, by setting
    ```toml

src/building/bootstrapping.md

@@ -55,7 +55,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/std`.
+which you can build with `./x.py build library/std`.
 See [Building the Compiler](/building/how-to-build-and-run.html#building-the-compiler).
 
 ### Stage 3
@@ -157,26 +157,26 @@ 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
+- `./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
   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 src/test/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 meaningful: it runs tests on the
+- `./x.py test --stage 0 src/test/ui` is not meaningful: it runs tests on the
   _beta_ compiler and doesn't build `rustc` from source. Use `test src/test/ui`
   instead, which builds stage 1 from source.
-- `x.py test --stage 0 compiler/rustc` builds the compiler but runs no tests:
+- `./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
   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
+- `./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/std` instead, which allows compiling programs without needing to define
   lang items.
 
@@ -348,7 +348,7 @@ You can find more discussion about sysroots in:
 
 [rustdoc PR]: https://github.com/rust-lang/rust/pull/76728
 
-### Directories and artifacts generated by x.py
+### Directories and artifacts generated by `x.py`
 
 The following tables indicate the outputs of various stage actions:
 

src/building/build-install-distribution-artifacts.md

@@ -18,7 +18,7 @@ test that it works on your target system. You’ll want to run this command:
 
    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.py install` for testing.
    Rather, you should create a toolchain as discussed in
    [here][create-rustup-toolchain].
 

src/building/compiler-documenting.md

@@ -4,7 +4,7 @@ You might want to build documentation of the various components
 available like the standard library. There’s two ways to go about this.
 You can run rustdoc directly on the file to make sure the HTML is
 correct, which is fast. Alternatively, you can build the documentation
-as part of the build process through x.py. Both are viable methods
+as part of the build process through `x.py`. Both are viable methods
 since documentation is more about the content.
 
 ## Document everything

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

@@ -20,7 +20,7 @@ cd rust
 
 ## Create a `config.toml`
 
-To start, run `x.py setup`. This will create a `config.toml` with reasonable defaults.
+To start, run `./x.py setup`. This will create a `config.toml` with reasonable defaults.
 
 You may also want to change some of the following settings (and possibly others, such as
 `llvm.ccache`):

src/building/new-target.md

@@ -8,7 +8,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.py
 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.

src/building/suggested.md

@@ -8,13 +8,13 @@ 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 --bless` on each commit, to ensure
+that will automatically run `./x.py test tidy --bless` on each commit, to ensure
 your code is up to par. If you decide later that this behavior is
 undesirable, you can delete the `pre-commit` file in `.git/hooks`.
 
 A prebuilt git hook lives at [`src/etc/pre-commit.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-commit.sh) which can be copied into your `.git/hooks` folder as `pre-commit` (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.py setup`!
 
 ## Configuring `rust-analyzer` for `rustc`
 
@@ -43,7 +43,7 @@ you can write: <!-- date: 2021-09 --><!-- the date comment is for the edition be
 ```
 
 in your `.vscode/settings.json` file. This will ask `rust-analyzer` to use
-`x.py check` to check the sources, and the stage 0 rustfmt to format them.
+`./x.py check` to check the sources, and the stage 0 rustfmt to format them.
 
 > NOTE: Make sure to replace `TARGET_TRIPLE` in the `rust-analyzer.rustfmt.overrideCommand`
 > setting with the appropriate target triple for your machine. An example of such
@@ -55,7 +55,7 @@ If you're running `coc.nvim`, you can use `:CocLocalConfig` to create a
 `editor.formatOnSave: true,` with
 `"coc.preferences.formatOnSaveFiletypes": ["rust"],`.
 
-If running `x.py check` on save is inconvenient, in VS Code you can use a [Build
+If running `./x.py check` on save is inconvenient, in VS Code you can use a [Build
 Task] instead:
 
 ```JSON

src/contributing.md

@@ -97,7 +97,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.py test` suite locally,
 since it takes a very long time to execute.
 
 After someone has reviewed your pull request, they will leave an annotation
@@ -173,32 +173,32 @@ differently from other crates that are directly in this repo:
 * [rustfmt](https://github.com/rust-lang/rustfmt)
 
 In contrast to `submodule` dependencies
-(see below for those), the `subtree` dependencies are just regular files and directories which can 
-be updated in tree. However, enhancements, bug fixes, etc. specific to these tools should be filed 
+(see below for those), the `subtree` dependencies are just regular files and directories which can
+be updated in tree. However, enhancements, bug fixes, etc. specific to these tools should be filed
 against the tools directly in their respective upstream repositories.
 
 #### Synchronizing a subtree
 
-Periodically the changes made to subtree based dependencies need to be synchronized between this 
+Periodically the changes made to subtree based dependencies need to be synchronized between this
 repository and the upstream tool repositories.
 
-Subtree synchronizations are typically handled by the respective tool maintainers. Other users 
-are welcome to submit synchronization PRs, however, in order to do so you you will need to modify 
-your local git installation and follow a very precise set of instructions. 
-These instructions are documented, along with several useful tips and tricks, in the 
-[syncing subtree changes][clippy-sync-docs] section in Clippy's Contributing guide. 
-The instructions are applicable for use with any subtree based tool, just be sure to 
-use the correct corresponding subtree directory and remote repository. 
+Subtree synchronizations are typically handled by the respective tool maintainers. Other users
+are welcome to submit synchronization PRs, however, in order to do so you you will need to modify
+your local git installation and follow a very precise set of instructions.
+These instructions are documented, along with several useful tips and tricks, in the
+[syncing subtree changes][clippy-sync-docs] section in Clippy's Contributing guide.
+The instructions are applicable for use with any subtree based tool, just be sure to
+use the correct corresponding subtree directory and remote repository.
 
 The synchronization process goes in two directions: `subtree push` and `subtree pull`.
 
-A `subtree push` takes all the changes that happened to the copy in this repo and creates commits 
-on the remote repo that match the local changes. Every local 
-commit that touched the subtree causes a commit on the remote repo, but 
+A `subtree push` takes all the changes that happened to the copy in this repo and creates commits
+on the remote repo that match the local changes. Every local
+commit that touched the subtree causes a commit on the remote repo, but
 is modified to move the files from the specified directory to the tool repo root.
 
-A `subtree pull` takes all changes since the last `subtree pull` 
-from the tool repo and adds these commits to the rustc repo along with a merge commit that moves 
+A `subtree pull` takes all changes since the last `subtree pull`
+from the tool repo and adds these commits to the rustc repo along with a merge commit that moves
 the tool changes into the specified directory in the rust repository.
 
 It is recommended that you always do a push first and get that merged to the tool master branch.

src/getting-started.md

@@ -128,13 +128,13 @@ this chapter for more info][config].
 In the top level of the repo:
 
 ```sh
-$ x.py setup
+$ ./x.py setup
 ```
 
-This will walk you through an interactive setup for x.py that looks like this:
+This will walk you through an interactive setup for `x.py` that looks like this:
 
 ```
-$ x.py setup
+$ ./x.py setup
 Welcome to the Rust project! What do you want to do with x.py?
 a) Contribute to the standard library
 b) Contribute to the compiler
@@ -150,13 +150,13 @@ To get started, try one of the following commands:
 For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggested.html
 ```
 
-Note that by default, `x.py setup` will use CI-built LLVM if available for your
+Note that by default, `./x.py setup` will use CI-built LLVM if available for your
 platform so that you don't need to build LLVM in addition to building the
 compiler. In some circumstances, such as when updating the version of LLVM used
 by `rustc`, you may want to temporarily disable this feature. See the ["Updating
 LLVM" section] for more.
 
-If you want to download LLVM from CI without running `x.py setup`, you can set
+If you want to download LLVM from CI without running `./x.py setup`, you can set
 the `download-ci-llvm` option to `true` in your `config.toml`:
 
 ```toml
@@ -166,7 +166,7 @@ download-ci-llvm = true
 
 ["Updating LLVM" section]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates
 
-### x.py Intro
+### `x.py` Intro
 
 `rustc` is a _bootstrapping_ compiler, which means that it is written in Rust
 and thus needs to be compiled by itself. So where do you
@@ -177,7 +177,7 @@ to build a new compiler. Then, we use that compiler to build itself. Thus,
 
 [boot]: ./building/bootstrapping.md
 
-We have a special tool `./x.py` that drives this process. It is used for
+We have a special tool `x.py` that drives this process. It is used for
 building the compiler, the standard libraries, and `rustdoc`. It is also used
 for driving CI and building the final release artifacts.
 
@@ -195,14 +195,14 @@ should still read the rest of the section:
 
 | Command | When to use it |
 | --- | --- |
-| `x.py check` | Quick check to see if things compile; [rust-analyzer can run this automatically for you][rust-analyzer] |
-| `x.py build --stage 0 [library/std]` | Build only the standard library, without building the compiler |
-| `x.py build library/std` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough |
-| `x.py build --keep-stage 1 library/std` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) |
-| `x.py test [--keep-stage 1]` | Run the test suite using the stage1 compiler |
-| `x.py test --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. |
-| `x.py build --stage 2 compiler/rustc` | Do a full 2-stage build. You almost never want to do this. |
-| `x.py test --stage 2` | Do a full 2-stage build and run all tests. You almost never want to do this. |
+| `./x.py check` | Quick check to see if things compile; [rust-analyzer can run this automatically for you][rust-analyzer] |
+| `./x.py build --stage 0 [library/std]` | Build only the standard library, without building the compiler |
+| `./x.py build library/std` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough |
+| `./x.py build --keep-stage 1 library/std` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) |
+| `./x.py test [--keep-stage 1]` | Run the test suite using the stage1 compiler |
+| `./x.py test --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. |
+| `./x.py build --stage 2 compiler/rustc` | Do a full 2-stage build. You almost never want to do this. |
+| `./x.py test --stage 2` | Do a full 2-stage build and run all tests. You almost never want to do this. |
 
 To do a full 2-stage build of the whole compiler, you should run this (after
 updating `config.toml` as mentioned above):
@@ -231,7 +231,7 @@ For most contributions, you only need to build stage 1, which saves a lot of tim
 ```
 
 This will take a while, especially the first time. Be wary of accidentally
-touching or formatting the compiler, as `./x.py` will try to recompile it.
+touching or formatting the compiler, as `x.py` will try to recompile it.
 
 **NOTE**: The `--keep-stage 1` will _assume_ that the stage 0 standard library
 does not need to be rebuilt, which is usually true, which will save some time.

src/git.md

@@ -158,7 +158,7 @@ These changes are not changes to files: they are changes to submodules (more on
 this [later](#git-submodules)). To get rid of those, run `git submodule update`
 (or run any `x.py` command, which will automatically update the submodules).
 Note that there is (as of <!-- date: 2021-07 --> July 2021) a [bug][#77620] if you use
-worktrees, submodules, and x.py in a commit hook.  If you run into an error
+worktrees, submodules, and `x.py` in a commit hook.  If you run into an error
 like:
 
 ```

src/profiling.md

@@ -44,7 +44,7 @@ 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.py` isn't normal :P
 
 # Do a clean before every run, to not mix in the results from previous runs.
 ./x.py clean
@@ -88,7 +88,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.py check`,
 you will be compiling rustc _a lot_.
 I recommend changing a few settings in `config.toml` to make it bearable:
 ```

src/tests/intro.md

@@ -3,7 +3,7 @@
 <!-- toc -->
 
 The Rust project runs a wide variety of different tests, orchestrated by
-the build system (`x.py test`).  The main test harness for testing the
+the build system (`./x.py test`).  The main test harness for testing the
 compiler itself is a tool called compiletest (located in the
 [`src/tools/compiletest`] directory). This section gives a brief
 overview of how the testing framework is setup, and then gets into some

src/tests/running.md

@@ -49,7 +49,7 @@ with the debuginfo test suite:
 ```
 
 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.py test`:
 
 ```bash
 ./x.py test src/test/ui/const-generics