replace config.toml to bootstrap.toml in src:doc:rustc-dev-guide

src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/backend/updating-llvm.md

@@ -144,7 +144,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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/how-to-build-and-run.md

@@ -159,15 +159,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
@@ -206,7 +206,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:
 
@@ -326,7 +326,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]
@@ -336,8 +336,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/doc/rustc-dev-guide/src/building/new-target.md

@@ -37,7 +37,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]
@@ -55,8 +55,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
 
@@ -141,14 +141,14 @@ 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 warnings, you may want to:
 - Modify the dependency to remove the warnings
-- Or for local development purposes, suppress the warnings by setting deny-warnings = false in config.toml.
+- Or for local development purposes, suppress the warnings by setting deny-warnings = false in bootstrap.toml.
 
 ```toml
-# config.toml
+# bootstrap.toml
 [rust]
 deny-warnings = false
 ```

src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/building/suggested.md

@@ -305,7 +305,7 @@ subsequent rebuilds:
 ```
 
 If you don't want to include the flag with every command, you can enable it in
-the `config.toml`:
+the `bootstrap.toml`:
 
 ```toml
 [rust]
@@ -384,20 +384,20 @@ ln -s ./src/tools/nix-dev-shell/envrc-shell ./.envrc # Use nix-shell
 ### Note
 
 Note that when using nix on a not-NixOS distribution, it may be necessary to set
-**`patch-binaries-for-nix = true` in `config.toml`**. Bootstrap tries to detect
+**`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/doc/rustc-dev-guide/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.
 
@@ -373,7 +373,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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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]`.
@@ -83,7 +83,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
@@ -115,7 +115,7 @@ human-readable coverage report.
 
 > Tests in `coverage-run` mode have an implicit `//@ needs-profiler-runtime`
 > 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-configtoml-settings).
 
 Finally, the [`tests/codegen/instrument-coverage/testprog.rs`] test compiles a simple Rust program
 with `-C instrument-coverage` and compares the compiled program's LLVM IR to

src/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/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/doc/rustc-dev-guide/src/profiling/with_rustc_perf.md

@@ -9,7 +9,7 @@ which will download and build the suite for you, build a local compiler toolchai
 
 You can use the `./x perf <command> [options]` command to use this integration.
 
-You can use normal bootstrap flags for this command, such as `--stage 1` or `--stage 2`, for example to modify the stage of the created sysroot. It might also be useful to configure `config.toml` to better support profiling, e.g. set `rust.debuginfo-level = 1` to add source line information to the built compiler.
+You can use normal bootstrap flags for this command, such as `--stage 1` or `--stage 2`, for example to modify the stage of the created sysroot. It might also be useful to configure `bootstrap.toml` to better support profiling, e.g. set `rust.debuginfo-level = 1` to add source line information to the built compiler.
 
 `x perf` currently supports the following commands:
 - `benchmark <id>`: Benchmark the compiler and store the results under the passed `id`.

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

@@ -58,12 +58,12 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
   * 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.
-  * For frontend debugging, disable the `rust.docs-minification` option in [`config.toml`].
+  * For frontend debugging, disable the `rust.docs-minification` option in [`bootstrap.toml`].
 * Use `./x test tests/rustdoc*` to run the tests using a stage1
   rustdoc.
   * See [Rustdoc internals] for more information about tests.
 
-[`config.toml`]: ./building/how-to-build-and-run.md
+[`bootstrap.toml`]: ./building/how-to-build-and-run.md
 
 ## Code structure
 

src/doc/rustc-dev-guide/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/sanitizer/`][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/doc/rustc-dev-guide/src/tests/ci.md

@@ -435,7 +435,7 @@ To learn more about the dashboard, see the [Datadog CI docs].
 
 ## Determining the CI configuration
 
-If you want to determine which `config.toml` settings are used in CI for a
+If you want to determine which `bootstrap.toml` settings are used in CI for a
 particular job, it is probably easiest to just look at the build log. To do
 this:
 

src/doc/rustc-dev-guide/src/tests/compiletest.md

@@ -525,10 +525,10 @@ data into a 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`:
+is enabled in `bootstrap.toml`:
 
 ```toml
-# config.toml
+# bootstrap.toml
 [build]
 profiler = true
 ```

src/doc/rustc-dev-guide/src/tests/directives.md

@@ -160,9 +160,9 @@ settings:
   stable support for `asm!`
 - `needs-profiler-runtime` — ignores the test if the profiler runtime was not
   enabled for the target
-  (`build.profiler = true` in rustc's `config.toml`)
+  (`build.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, MemorySanitizer or
@@ -172,7 +172,7 @@ settings:
   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`)
+  true` in `bootstrap.toml`)
 - `needs-threads` — ignores if the target does not have threading support
 - `needs-subprocess`  — ignores if the target does not have subprocess support
 - `needs-symlink` — ignores if the target does not support symlinks. This can be

src/doc/rustc-dev-guide/src/tests/docker.md

@@ -21,7 +21,7 @@ The [`src/ci/docker/run.sh`] script is used to build a specific Docker image, ru
 build Rust within the image, and either run tests or prepare a set of archives designed for distribution. The script will mount your local Rust source tree in read-only mode, and an `obj` directory in read-write mode. All the compiler artifacts will be stored in the `obj` directory. The shell will start out in the `obj`directory. From there, it will execute `../src/ci/run.sh` which starts the build as defined by the Docker image.
 
 You can run `src/ci/docker/run.sh <image-name>` directly. A few important notes regarding the `run.sh` script:
-- When executed on CI, the script expects that all submodules are checked out. If some submodule that is accessed by the job is not available, the build will result in an error. You should thus make sure that you have all required submodules checked out locally. You can either do that manually through git, or set `submodules = true` in your `config.toml` and run a command such as `x build` to let bootstrap download the most important submodules (this might not be enough for the given CI job that you are trying to execute though).
+- When executed on CI, the script expects that all submodules are checked out. If some submodule that is accessed by the job is not available, the build will result in an error. You should thus make sure that you have all required submodules checked out locally. You can either do that manually through git, or set `submodules = true` in your `bootstrap.toml` and run a command such as `x build` to let bootstrap download the most important submodules (this might not be enough for the given CI job that you are trying to execute though).
 - `<image-name>` corresponds to a single directory located in one of the `src/ci/docker/host-*` directories. Note that image name does not necessarily correspond to a job name, as some jobs execute the same image, but with different environment variables or Docker build arguments (this is a part of the complexity that makes it difficult to run CI jobs locally).
 - If you are executing a "dist" job (job beginning with `dist-`), you should set the `DEPLOY=1` environment variable.
 - If you are executing an "alternative dist" job (job beginning with `dist-` and ending with `-alt`), you should set the `DEPLOY_ALT=1` environment variable.

src/doc/rustc-dev-guide/src/tests/running.md

@@ -189,7 +189,7 @@ just like when running the tests without the `--bless` flag.
 
 There are a few options for running tests:
 
-* `config.toml` has the `rust.verbose-tests` option. If `false`, each test will
+* `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
   harness](https://doc.rust-lang.org/rustc/tests/).
@@ -353,7 +353,7 @@ coordinate running tests (see [src/bootstrap/src/core/build_steps/test.rs]).
 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

src/doc/rustc-dev-guide/src/tracing.md

@@ -185,11 +185,11 @@ rustc.
 
 While calls to `error!`, `warn!` and `info!` are included in every build of the compiler,
 calls to `debug!` and `trace!` are only included in the program if
-`debug-logging=true` is turned on in config.toml (it is
+`debug-logging=true` is turned on in bootstrap.toml (it is
 turned off by default), so if you don't see `DEBUG` logs, especially
 if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see
 `INFO` logs, make sure that `debug-logging=true` is turned on in your
-config.toml.
+bootstrap.toml.
 
 ## Logging etiquette and conventions