Auto merge of #137081 - Shourya742:2025-02-15-change-config.toml-to-bootstrap.toml, r=onur-ozkan,jieyouxu,kobzol

change config.toml to bootstrap.toml

Currently, both Bootstrap and Cargo uses same name as their configuration file, which can be confusing. This PR is based on a discussion to rename `config.toml` to `bootstrap.toml` for Bootstrap. Closes: rust-lang/rust#126875.

I have split the PR into atomic commits to make it easier to review. Once the changes are finalized, I will squash them. I am particularly concerned about the changes made to modules that are not part of Bootstrap. How should we handle those changes? Should we ping the respective maintainers?

Author: bors

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

@@ -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/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

@@ -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/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/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/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/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/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]`.
@@ -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