Rename config.toml to bootstrap.toml

src/backend/debugging.md

@@ -38,7 +38,7 @@ which means that LLVM assertion failures can show up as compiler crashes (not
 ICEs but "real" crashes) and other sorts of weird behavior. If you are
 encountering these, it is a good idea to try using a compiler with LLVM
 assertions enabled - either an "alt" nightly or a compiler you build yourself
-by setting `[llvm] assertions=true` in your config.toml - and see whether
+by setting `[llvm] assertions=true` in your bootstrap.toml - and see whether
 anything turns up.
 
 The rustc build process builds the LLVM tools into
@@ -160,7 +160,7 @@ from `./build/<host-triple>/llvm/bin/` with the LLVM IR emitted by rustc.
 When investigating the implementation of LLVM itself, you should be
 aware of its [internal debug infrastructure][llvm-debug].
 This is provided in LLVM Debug builds, which you enable for rustc
-LLVM builds by changing this setting in the config.toml:
+LLVM builds by changing this setting in the bootstrap.toml:
 ```
 [llvm]
 # Indicates whether the LLVM assertions are enabled or not

src/backend/updating-llvm.md

@@ -101,7 +101,7 @@ so let's go through each in detail.
    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`:
+   This is done by having the following setting in `bootstrap.toml`:
 
    ```toml
    [llvm]

src/building/compiler-documenting.md

@@ -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 doc`, modify `config.toml`:
+  To create it by default with `x doc`, modify `bootstrap.toml`:
 
   ```toml
   [build]

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

@@ -139,15 +139,15 @@ similar to the one 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`
+## Create a `bootstrap.toml`
 
 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
+and create a `bootstrap.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`)
 as the build process may be different for other defaults.
 
-Alternatively, you can write `config.toml` by hand. See `config.example.toml` for all the available
+Alternatively, you can write `bootstrap.toml` by hand. See `bootstrap.example.toml` for all the available
 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
@@ -186,7 +186,7 @@ See the chapters on
 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
+Once you've created a `bootstrap.toml`, you are now ready to run
 `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:
 
@@ -306,7 +306,7 @@ involve proc macros or build scripts, you must be sure to explicitly build targe
 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 build`,
-you can configure this in the `[build]` section of your `config.toml` like so:
+you can configure this in the `[build]` section of your `bootstrap.toml` like so:
 
 ```toml
 [build]
@@ -316,8 +316,8 @@ target = ["x86_64-unknown-linux-gnu", "wasm32-wasip1"]
 Note that building for some targets requires having external dependencies installed
 (e.g. building musl targets requires a local copy of musl).
 Any target-specific configuration (e.g. the path to a local copy of musl)
-will need to be provided by your `config.toml`.
-Please see `config.example.toml` for information on target-specific configuration keys.
+will need to be provided by your `bootstrap.toml`.
+Please see `bootstrap.example.toml` for information on target-specific configuration keys.
 
 For examples of the complete configuration necessary to build a target, please visit
 [the rustc book](https://doc.rust-lang.org/rustc/platform-support.html),

src/building/new-target.md

@@ -33,7 +33,7 @@ able to configure Rust to treat your build as the system LLVM to avoid
 redundant builds.
 
 You can tell Rust to use a pre-built version of LLVM using the `target` section
-of `config.toml`:
+of `bootstrap.toml`:
 
 ```toml
 [target.x86_64-unknown-linux-gnu]
@@ -51,8 +51,8 @@ for codegen tests. This tool is normally built with LLVM, but if you use your
 own preinstalled LLVM, you will need to provide `FileCheck` in some other way.
 On Debian-based systems, you can install the `llvm-N-tools` package (where `N`
 is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify
-the path to `FileCheck` with the `llvm-filecheck` config item in `config.toml`
-or you can disable codegen test with the `codegen-tests` item in `config.toml`.
+the path to `FileCheck` with the `llvm-filecheck` config item in `bootstrap.toml`
+or you can disable codegen test with the `codegen-tests` item in `bootstrap.toml`.
 
 ## Creating a target specification
 
@@ -137,7 +137,7 @@ After this, run `cargo update -p libc` to update the lockfiles.
 
 Beware that if you patch to a local `path` dependency, this will enable
 warnings for that dependency. Some dependencies are not warning-free, and due
-to the `deny-warnings` setting in `config.toml`, the build may suddenly start
+to the `deny-warnings` setting in `bootstrap.toml`, the build may suddenly start
 to fail. To work around the warnings, you may want to disable `deny-warnings`
 in the config, or modify the dependency to remove the warnings.
 

src/building/optimized-build.md

@@ -13,7 +13,7 @@ This page describes how you can use these approaches when building `rustc` yours
 
 Link-time optimization is a powerful compiler technique that can increase program performance. To
 enable (Thin-)LTO when building `rustc`, set the `rust.lto` config option to `"thin"`
-in `config.toml`:
+in `bootstrap.toml`:
 
 ```toml
 [rust]
@@ -34,7 +34,7 @@ Enabling LTO on Linux has [produced] speed-ups by up to 10%.
 
 Using a different memory allocator for `rustc` can provide significant performance benefits. If you
 want to enable the `jemalloc` allocator, you can set the `rust.jemalloc` option to `true`
-in `config.toml`:
+in `bootstrap.toml`:
 
 ```toml
 [rust]
@@ -46,7 +46,7 @@ jemalloc = true
 ## Codegen units
 
 Reducing the amount of codegen units per `rustc` crate can produce a faster build of the compiler.
-You can modify the number of codegen units for `rustc` and `libstd` in `config.toml` with the
+You can modify the number of codegen units for `rustc` and `libstd` in `bootstrap.toml` with the
 following options:
 
 ```toml
@@ -67,7 +67,7 @@ RUSTFLAGS="-C target_cpu=x86-64-v3" ./x build ...
 ```
 
 If you also want to compile LLVM for a specific instruction set, you can set `llvm` flags
-in `config.toml`:
+in `bootstrap.toml`:
 
 ```toml
 [llvm]

src/building/prerequisites.md

@@ -38,4 +38,4 @@ incremental compilation ([see here][config]). This will make compilation take
 longer (especially after a rebase), but will save a ton of space from the
 incremental caches.
 
-[config]: ./how-to-build-and-run.md#create-a-configtoml
+[config]: ./how-to-build-and-run.md#create-a-bootstraptoml

src/building/suggested.md

@@ -207,7 +207,7 @@ time in subsequent rebuilds:
 ```
 
 If you don't want to include the flag with every command, you can
-enable it in the `config.toml`:
+enable it in the `bootstrap.toml`:
 
 ```toml
 [rust]
@@ -293,20 +293,20 @@ pkgs.mkShell {
 ```
 
 Note that when using nix on a not-NixOS distribution, it may be necessary to set
-**`patch-binaries-for-nix = true` in `config.toml`**.
+**`patch-binaries-for-nix = true` in `bootstrap.toml`**.
 Bootstrap tries to detect whether it's running in nix and enable patching automatically,
 but this detection can have false negatives.
 
-You can also use your nix shell to manage `config.toml`:
+You can also use your nix shell to manage `bootstrap.toml`:
 
 ```nix
 let
   config = pkgs.writeText "rustc-config" ''
-    # Your config.toml content goes here
+    # Your bootstrap.toml content goes here
   ''
 pkgs.mkShell {
   /* ... */
-  # This environment variable tells bootstrap where our config.toml is.
+  # This environment variable tells bootstrap where our bootstrap.toml is.
   RUST_BOOTSTRAP_CONFIG = config;
 }
 ```

src/compiler-debugging.md

@@ -11,13 +11,13 @@ chapter](./backend/debugging.md)).
 ## Configuring the compiler
 
 By default, rustc is built without most debug information. To enable debug info,
-set `debug = true` in your config.toml.
+set `debug = true` in your bootstrap.toml.
 
 Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`,
 `debug-logging`, etc.) which can be individually tweaked if you want to, but many people
 simply set `debug = true`.
 
-If you want to use GDB to debug rustc, please set `config.toml` with options:
+If you want to use GDB to debug rustc, please set `bootstrap.toml` with options:
 
 ```toml
 [rust]
@@ -35,14 +35,14 @@ debuginfo-level = 2
 
 The default configuration will enable `symbol-mangling-version` v0.
 This requires at least GDB v10.2,
-otherwise you need to disable new symbol-mangling-version in `config.toml`.
+otherwise you need to disable new symbol-mangling-version in `bootstrap.toml`.
 
 ```toml
 [rust]
 new-symbol-mangling = false
 ```
 
-> See the comments in `config.example.toml` for more info.
+> See the comments in `bootstrap.example.toml` for more info.
 
 You will need to rebuild the compiler after changing any configuration option.
 
@@ -335,7 +335,7 @@ error: aborting due to previous error
 
 ## Configuring CodeLLDB for debugging `rustc`
 
-If you are using VSCode, and have edited your `config.toml` to request debugging
+If you are using VSCode, and have edited your `bootstrap.toml` to request debugging
 level 1 or 2 for the parts of the code you're interested in, then you should be
 able to use the [CodeLLDB] extension in VSCode to debug it.
 

src/fuzzing.md

@@ -123,7 +123,7 @@ what actually results in superior throughput.
 You may want to build rustc from source with debug assertions to find
 additional bugs, though this is a trade-off: it can slow down fuzzing by
 requiring extra work for every execution. To enable debug assertions, add this
-to `config.toml` when compiling rustc:
+to `bootstrap.toml` when compiling rustc:
 
 ```toml
 [rust]

src/llvm-coverage-instrumentation.md

@@ -34,7 +34,7 @@ Detailed instructions and examples are documented in the
 [coverage map]: https://llvm.org/docs/CoverageMappingFormat.html
 [rustc-book-instrument-coverage]: https://doc.rust-lang.org/nightly/rustc/instrument-coverage.html
 
-## Recommended `config.toml` settings
+## Recommended `bootstrap.toml` settings
 
 When working on the coverage instrumentation code, it is usually necessary to
 **enable the profiler runtime** by setting `profiler = true` in `[build]`.
@@ -85,7 +85,7 @@ statically links coverage-instrumented binaries with LLVM runtime code
 In the `rustc` source tree,
 `library/profiler_builtins` bundles the LLVM `compiler-rt` code into a Rust library crate.
 Note that when building `rustc`,
-`profiler_builtins` is only included when `build.profiler = true` is set in `config.toml`.
+`profiler_builtins` is only included when `build.profiler = true` is set in `bootstrap.toml`.
 
 When compiling with `-C instrument-coverage`,
 [`CrateLoader::postprocess()`][crate-loader-postprocess] dynamically loads
@@ -319,7 +319,7 @@ human-readable coverage report.
 
 > Tests in `coverage-run` mode have an implicit `// needs-profiler-support`
 > directive, so they will be skipped if the profiler runtime has not been
-> [enabled in `config.toml`](#recommended-configtoml-settings).
+> [enabled in `bootstrap.toml`](#recommended-bootstraptoml-settings).
 
 Finally, the [`coverage-llvmir`] test compiles a simple Rust program
 with `-C instrument-coverage` and compares the compiled program's LLVM IR to

src/overview.md

@@ -351,7 +351,7 @@ approach is to turn [`RefCell`]s into [`Mutex`]s -- that is, we
 switch to thread-safe internal mutability. However, there are ongoing
 challenges with lock contention, maintaining query-system invariants under
 concurrency, and the complexity of the code base. One can try out the current
-work by enabling parallel compilation in `config.toml`. It's still early days,
+work by enabling parallel compilation in `bootstrap.toml`. It's still early days,
 but there are already some promising performance improvements.
 
 [`RefCell`]: https://doc.rust-lang.org/std/cell/struct.RefCell.html

src/parallel-rustc.md

@@ -6,7 +6,7 @@ parallel implementations, such as query evaluation, type check and
 monomorphization, but the general version of the compiler does not include 
 these parallelization functions. **To try out the current parallel compiler**, 
 one can install rustc from source code with `parallel-compiler = true` in 
-the `config.toml`.
+the `bootstrap.toml`.
 
 The lack of parallelism at other stages (for example, macro expansion) also 
 represents an opportunity for improving compiler performance.

src/profile-guided-optimization.md

@@ -120,7 +120,7 @@ The `rustc` version of this can be found in `library/profiler_builtins` which
 basically packs the C code from `compiler-rt` into a Rust crate.
 
 In order for `profiler_builtins` to be built, `profiler = true` must be set
-in `rustc`'s `config.toml`.
+in `rustc`'s `bootstrap.toml`.
 
 [compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/profile
 

src/profiling.md

@@ -87,7 +87,7 @@ Example output for the compiler:
 
 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:
+I recommend changing a few settings in `bootstrap.toml` to make it bearable:
 ```
 [rust]
 # A debug build takes _a third_ as long on my machine,

src/profiling/with_perf.md

@@ -6,7 +6,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or
 
 - Get a clean checkout of rust-lang/master, or whatever it is you want
   to profile.
-- Set the following settings in your `config.toml`:
+- Set the following settings in your `bootstrap.toml`:
   - `debuginfo-level = 1` - enables line debuginfo
   - `jemalloc = false` - lets you do memory use profiling with valgrind
   - leave everything else the defaults

src/profiling/wpa_profiling.md

@@ -44,7 +44,7 @@ compiler we're using to build rustc will aid our analysis greatly by allowing WP
 symbols correctly. Unfortunately, the stage 0 compiler does not have symbols turned on which is why
 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
+To do this, make sure you have set `debuginfo-level = 1` in your `bootstrap.toml` file. This tells
 rustc to generate debug information which includes stack frames when bootstrapping.
 
 Now you can build the stage 1 compiler: `x build --stage 1 -i library` or however

src/sanitizers.md

@@ -32,7 +32,7 @@ implementation:
 
 *  The sanitizer runtime libraries are part of the [compiler-rt] project, and
    [will be built][sanitizer-build] on [supported targets][sanitizer-targets]
-   when enabled in `config.toml`:
+   when enabled in `bootstrap.toml`:
 
    ```toml
    [build]
@@ -80,7 +80,7 @@ Sanitizers are validated by code generation tests in
 [`tests/ui/sanitize/`][test-ui] directory.
 
 Testing sanitizer functionality requires the sanitizer runtimes (built when
-`sanitizer = true` in `config.toml`) and target providing support for particular
+`sanitizer = true` in `bootstrap.toml`) and target providing support for particular
 sanitizer. When sanitizer is unsupported on given target, sanitizers tests will
 be ignored. This behaviour is controlled by compiletest `needs-sanitizer-*`
 directives.

src/tests/compiletest.md

@@ -491,10 +491,10 @@ human-readable code coverage report.
 
 Instrumented binaries need to be linked against the LLVM profiler runtime,
 so `coverage-run` tests are **automatically skipped**
-unless the profiler runtime is enabled in `config.toml`:
+unless the profiler runtime is enabled in `bootstrap.toml`:
 
 ```toml
-# config.toml
+# bootstrap.toml
 [build]
 profiler = true
 ```

src/tests/docker.md

@@ -24,7 +24,7 @@ Alternatively, you can run individual commands to do specific tasks. For
 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.
+`bootstrap.toml` so that it doesn't attempt to modify the read-only directory.
 
 Some additional notes about using the Docker images:
 

src/tests/headers.md

@@ -150,9 +150,9 @@ The following header commands will check rustc build settings and target setting
 * `needs-asm-support` — ignores if it is running on a target that doesn't have
   stable support for `asm!`
 * `needs-profiler-support` — ignores if profiler support was not enabled for
-  the target (`profiler = true` in rustc's `config.toml`)
+  the target (`profiler = true` in rustc's `bootstrap.toml`)
 * `needs-sanitizer-support` — ignores if the sanitizer support was not enabled
-  for the target (`sanitizers = true` in rustc's `config.toml`)
+  for the target (`sanitizers = true` in rustc's `bootstrap.toml`)
 * `needs-sanitizer-{address,hwaddress,leak,memory,thread}` — ignores
   if the corresponding sanitizer is not enabled for the target
   (AddressSanitizer, hardware-assisted AddressSanitizer, LeakSanitizer,
@@ -162,7 +162,7 @@ The following header commands will check rustc build settings and target setting
   --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
-  (`rust.lld = true` in `config.toml`)
+  (`rust.lld = true` in `bootstrap.toml`)
 * `needs-threads` — ignores if the target does not have threading support
 * `needs-symlink` — ignores if the target does not support symlinks. This can be the case on Windows
   if the developer did not enable priviledged symlink permissions.

src/tests/running.md

@@ -160,7 +160,7 @@ all tests. Of course you can also target just specific tests with the
 
 There are a few options for running tests:
 
-* `config.toml` has the `rust.verbose-tests` option.
+* `bootstrap.toml` has the `rust.verbose-tests` option.
   If `false`, each test will print a single dot (the default).
   If `true`, the name of every test will be printed.
   This is equivalent to the `--quiet` option in the [Rust test
@@ -341,7 +341,7 @@ communicate with the server to coordinate running tests (see
 First thing to know is that it only supports linux x86_64 at the moment. We will
 extend its support later on.
 
-You need to update `codegen-backends` value in your `config.toml` file in the
+You need to update `codegen-backends` value in your `bootstrap.toml` file in the
 `[rust]` section and add "gcc" in the array:
 
 ```toml