mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge from rustc

This commit is contained in:
The Miri Cronjob Bot 2025-03-20 05:10:41 +00:00
parent a308ff6d00 96a3c76fd5
commit 32ad01cea8
27 changed files with 114 additions and 88 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
rust-version
View File

@ -1 +1 @@
8536f201ffdb2c24925d7f9e87996d7dca93428b
493c38ba371929579fe136df26eccd9516347c7a

4
src/backend/debugging.md
View File

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

2
src/backend/updating-llvm.md
View File

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

2
src/building/compiler-documenting.md
View File

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

14
src/building/how-to-build-and-run.md
View File

@ -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),

12
src/building/new-target.md
View File

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

8
src/building/optimized-build.md
View File

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

36
src/building/suggested.md
View File

@ -123,6 +123,30 @@ Another way is without a plugin, and creating your own logic in your
configuration. The following code will work for any checkout of rust-lang/rust (newer than Febuary 2025):
```lua
local function expand_config_variables(option)
local var_placeholders = {
['${workspaceFolder}'] = function(_)
return vim.lsp.buf.list_workspace_folders()[1]
end,
}
if type(option) == "table" then
local mt = getmetatable(option)
local result = {}
for k, v in pairs(option) do
result[expand_config_variables(k)] = expand_config_variables(v)
end
return setmetatable(result, mt)
end
if type(option) ~= "string" then
return option
end
local ret = option
for key, fn in pairs(var_placeholders) do
ret = ret:gsub(key, fn)
end
return ret
end
lspconfig.rust_analyzer.setup {
root_dir = function()
local default = lspconfig.rust_analyzer.config_def.default_config.root_dir()
@ -142,7 +166,7 @@ lspconfig.rust_analyzer.setup {
-- load rust-lang/rust settings
local file = io.open(config)
local json = vim.json.decode(file:read("*a"))
client.config.settings["rust-analyzer"] = json.lsp["rust-analyzer"].initialization_options
client.config.settings["rust-analyzer"] = expand_config_variables(json.lsp["rust-analyzer"].initialization_options)
client.notify("workspace/didChangeConfiguration", { settings = client.config.settings })
end
return true
@ -305,7 +329,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 +408,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;
}
```

10
src/compiler-debugging.md
View File

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

2
src/contributing.md
View File

@ -81,7 +81,7 @@ smaller user-facing changes.
into a PR that ends up not getting merged!** [See this document][mcpinfo] for
more info on MCPs.
[mcpinfo]: https://forge.rust-lang.org/compiler/mcp.html
[mcpinfo]: https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#how-do-i-submit-an-mcp
[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler
### Performance

2
src/fuzzing.md
View File

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

2
src/implementing_new_features.md
View File

@ -44,7 +44,7 @@ like this; for example, the compiler team recommends
filing a Major Change Proposal ([MCP][mcp]) as a lightweight way to
garner support and feedback without requiring full consensus.
[mcp]: https://forge.rust-lang.org/compiler/mcp.html#public-facing-changes-require-rfcbot-fcp
[mcp]: https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#how-do-i-submit-an-mcp
You don't need to have the implementation fully ready for r+ to propose an FCP,
but it is generally a good idea to have at least a proof

6
src/llvm-coverage-instrumentation.md
View File

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

2
src/overview.md
View File

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

2
src/profile-guided-optimization.md
View File

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

2
src/profiling.md
View File

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

2
src/profiling/with_perf.md
View File

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

2
src/profiling/with_rustc_perf.md
View File

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

2
src/profiling/wpa_profiling.md
View File

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

4
src/rustdoc.md
View File

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

4
src/sanitizers.md
View File

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

4
src/tests/ci.md
View File

@ -180,6 +180,8 @@ their results can be seen [here](https://github.com/rust-lang-ci/rust/actions),
although usually you will be notified of the result by a comment made by bors on
the corresponding PR.
Note that if you start the default try job using `@bors try`, it will skip building several `dist` components and running post-optimization tests, to make the build duration shorter. If you want to execute the full build as it would happen before a merge, add an explicit `try-job` pattern with the name of the default try job (currently `dist-x86_64-linux`).
Multiple try builds can execute concurrently across different PRs.
<div class="warning">
@ -435,7 +437,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:

4
src/tests/compiletest.md
View File

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

6
src/tests/directives.md
View File

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

2
src/tests/docker.md
View File

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

60
src/tests/running.md
View File

@ -18,7 +18,7 @@ a subset of test collections, and merge queue CI will exercise all of the test
collection.
</div>
```bash
```text
./x test
```
@ -45,7 +45,7 @@ tests. For example, a good "smoke test" that can be used after modifying rustc
to see if things are generally working correctly would be to exercise the `ui`
test suite ([`tests/ui`]):
```bash
```text
./x test tests/ui
```
@ -53,14 +53,14 @@ Of course, the choice of test suites is
somewhat arbitrary, and may not suit the task you are doing. For example, if you
are hacking on debuginfo, you may be better off with the debuginfo test suite:
```bash
```text
./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 as a filter to `./x test`:
```bash
```text
./x test tests/ui/const-generics
```
@ -73,7 +73,7 @@ suite, you can pass that directory as a filter to `./x test`:
Likewise, you can test a single file by passing its path:
```bash
```text
./x test tests/ui/const-generics/const-test.rs
```
@ -81,19 +81,19 @@ Likewise, you can test a single file by passing its path:
have to use the `--test-args` argument as described
[below](#running-an-individual-test).
```bash
```text
./x test src/tools/miri --test-args tests/fail/uninit/padding-enum.rs
```
### Run only the tidy script
```bash
```text
./x test tidy
```
### Run tests on the standard library
```bash
```text
./x test --stage 0 library/std
```
@ -102,13 +102,13 @@ crates, you have to specify those explicitly.
### Run the tidy script and tests on the standard library
```bash
```text
./x test --stage 0 tidy library/std
```
### Run tests on the standard library using a stage 1 compiler
```bash
```text
./x test --stage 1 library/std
```
@ -122,7 +122,7 @@ the tests **usually** work fine with stage 1, there are some limitations.
### Run all tests using a stage 2 compiler
```bash
```text
./x test --stage 2
```
@ -134,13 +134,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
```text
./x test compiler/rustc_data_structures/src/thin_vec/tests.rs
```
But unfortunately, it's impossible. You should invoke the following instead:
```bash
```text
./x test compiler/rustc_data_structures/ --test-args thin_vec
```
@ -151,7 +151,7 @@ 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` with the
`--test-args` option:
```bash
```text
./x test tests/ui --test-args issue-1234
```
@ -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/).
@ -203,7 +203,7 @@ When `--pass $mode` is passed, these tests will be forced to run under the given
`$mode` unless the directive `//@ ignore-pass` exists in the test file. For
example, you can run all the tests in `tests/ui` as `check-pass`:
```bash
```text
./x test tests/ui --pass check
```
@ -219,7 +219,7 @@ first look for expected output in `foo.polonius.stderr`, falling back to the
usual `foo.stderr` if not found. The following will run the UI test suite in
Polonius mode:
```bash
```text
./x test tests/ui --compare-mode=polonius
```
@ -232,7 +232,7 @@ just `.rs` files, so after [creating a rustup
toolchain](../building/how-to-build-and-run.md#creating-a-rustup-toolchain), you
can do something like:
```bash
```text
rustc +stage1 tests/ui/issue-1234.rs
```
@ -252,7 +252,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
```text
./x build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu
```
@ -264,7 +264,7 @@ On the remote machine, run the `remote-test-server` with the `--bind
0.0.0.0:12345` flag (and optionally `-v` for verbose output). Output should look
like this:
```sh
```text
$ ./remote-test-server -v --bind 0.0.0.0:12345
starting test server
listening on 0.0.0.0:12345!
@ -278,7 +278,7 @@ restrictive IP address when binding.
You can test if the `remote-test-server` is working by connecting to it and
sending `ping\n`. It should reply `pong`:
```sh
```text
$ nc $REMOTE_IP 12345
ping
pong
@ -288,7 +288,7 @@ To run tests using the remote runner, set the `TEST_DEVICE_ADDR` environment
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
```text
export TEST_DEVICE_ADDR="1.2.3.4:12345"
./x test tests/ui --target riscv64gc-unknown-linux-gnu
```
@ -296,7 +296,7 @@ export TEST_DEVICE_ADDR="1.2.3.4:12345"
If `remote-test-server` was run with the verbose flag, output on the test
machine may look something like
```
```text
[...]
run "/tmp/work/test1007/a"
run "/tmp/work/test1008/a"
@ -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
@ -362,21 +362,21 @@ codegen-backends = ["llvm", "gcc"]
Then you need to install libgccjit 12. For example with `apt`:
```bash
$ apt install libgccjit-12-dev
```text
apt install libgccjit-12-dev
```
Now you can run the following command:
```bash
$ ./x test compiler/rustc_codegen_gcc/
```text
./x test compiler/rustc_codegen_gcc/
```
If it cannot find the `.so` library (if you installed it with `apt` for example), you
need to pass the library file path with `LIBRARY_PATH`:
```bash
$ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/ ./x test compiler/rustc_codegen_gcc/
```text
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/ ./x test compiler/rustc_codegen_gcc/
```
If you encounter bugs or problems, don't hesitate to open issues on the

4
src/tracing.md
View File

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