Merge from rustc
This commit is contained in:
Boxy
commit
815c5d4eee
2179 changed files with 29115 additions and 16932 deletions
|
|
@ -18,8 +18,8 @@ use std::path::Path;
|
|||
|
||||
use rustc_ast_pretty::pprust::item_to_string;
|
||||
use rustc_data_structures::sync::Lrc;
|
||||
use rustc_driver::{Compilation, RunCompiler};
|
||||
use rustc_interface::interface::Compiler;
|
||||
use rustc_driver::{Compilation, run_compiler};
|
||||
use rustc_interface::interface::{Compiler, Config};
|
||||
use rustc_middle::ty::TyCtxt;
|
||||
|
||||
struct MyFileLoader;
|
||||
|
|
@ -51,6 +51,10 @@ fn main() {
|
|||
struct MyCallbacks;
|
||||
|
||||
impl rustc_driver::Callbacks for MyCallbacks {
|
||||
fn config(&mut self, config: &mut Config) {
|
||||
config.file_loader = Some(Box::new(MyFileLoader));
|
||||
}
|
||||
|
||||
fn after_crate_root_parsing(
|
||||
&mut self,
|
||||
_compiler: &Compiler,
|
||||
|
|
@ -83,10 +87,5 @@ impl rustc_driver::Callbacks for MyCallbacks {
|
|||
}
|
||||
|
||||
fn main() {
|
||||
match RunCompiler::new(&["main.rs".to_string()], &mut MyCallbacks) {
|
||||
mut compiler => {
|
||||
compiler.set_file_loader(Some(Box::new(MyFileLoader)));
|
||||
compiler.run();
|
||||
}
|
||||
}
|
||||
run_compiler(&["main.rs".to_string()], &mut MyCallbacks);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ use std::path::Path;
|
|||
|
||||
use rustc_ast_pretty::pprust::item_to_string;
|
||||
use rustc_data_structures::sync::Lrc;
|
||||
use rustc_driver::{Compilation, RunCompiler};
|
||||
use rustc_interface::interface::Compiler;
|
||||
use rustc_driver::{Compilation, run_compiler};
|
||||
use rustc_interface::interface::{Compiler, Config};
|
||||
use rustc_middle::ty::TyCtxt;
|
||||
|
||||
struct MyFileLoader;
|
||||
|
|
@ -51,6 +51,10 @@ fn main() {
|
|||
struct MyCallbacks;
|
||||
|
||||
impl rustc_driver::Callbacks for MyCallbacks {
|
||||
fn config(&mut self, config: &mut Config) {
|
||||
config.file_loader = Some(Box::new(MyFileLoader));
|
||||
}
|
||||
|
||||
fn after_crate_root_parsing(
|
||||
&mut self,
|
||||
_compiler: &Compiler,
|
||||
|
|
@ -90,10 +94,5 @@ impl rustc_driver::Callbacks for MyCallbacks {
|
|||
}
|
||||
|
||||
fn main() {
|
||||
match RunCompiler::new(&["main.rs".to_string()], &mut MyCallbacks) {
|
||||
mut compiler => {
|
||||
compiler.set_file_loader(Some(Box::new(MyFileLoader)));
|
||||
compiler.run();
|
||||
}
|
||||
}
|
||||
run_compiler(&["main.rs".to_string()], &mut MyCallbacks);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Debugging bootstrap
|
||||
|
||||
> FIXME: this page could be expanded
|
||||
> FIXME: this section should be expanded
|
||||
|
||||
## `tracing` in bootstrap
|
||||
|
||||
|
|
@ -10,21 +10,69 @@ Bootstrap has conditional [`tracing`][tracing] setup to provide structured loggi
|
|||
|
||||
### Enabling `tracing` output
|
||||
|
||||
Bootstrap will conditionally enable `tracing` output if the `BOOTSTRAP_TRACING` env var is set.
|
||||
Bootstrap will conditionally build `tracing` support and enable `tracing` output if the `BOOTSTRAP_TRACING` env var is set.
|
||||
|
||||
Example usage:
|
||||
#### Basic usage
|
||||
|
||||
Example basic usage[^just-trace]:
|
||||
|
||||
[^just-trace]: It is not recommend to use *just* `BOOTSTRAP_TRACING=TRACE` because that will dump *everything* at `TRACE` level, including logs intentionally gated behind custom targets as they are too verbose even for `TRACE` level by default.
|
||||
|
||||
```bash
|
||||
$ BOOTSTRAP_TRACING=TRACE ./x build library --stage 1
|
||||
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x build library --stage 1
|
||||
```
|
||||
|
||||
Example output[^experimental]:
|
||||
Example output[^unstable]:
|
||||
|
||||
|
||||
```
|
||||
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap/
|
||||
Building bootstrap
|
||||
Compiling bootstrap v0.0.0 (/home/joe/repos/rust/src/bootstrap)
|
||||
Finished `dev` profile [unoptimized] target(s) in 2.74s
|
||||
DEBUG bootstrap parsing flags
|
||||
bootstrap::core::config::flags::Flags::parse args=["check", "src/bootstrap/"]
|
||||
DEBUG bootstrap parsing config based on flags
|
||||
DEBUG bootstrap creating new build based on config
|
||||
bootstrap::Build::build
|
||||
TRACE bootstrap setting up job management
|
||||
TRACE bootstrap downloading rustfmt early
|
||||
bootstrap::handling hardcoded subcommands (Format, Suggest, Perf)
|
||||
DEBUG bootstrap not a hardcoded subcommand; returning to normal handling, cmd=Check { all_targets: false }
|
||||
DEBUG bootstrap handling subcommand normally
|
||||
bootstrap::executing real run
|
||||
bootstrap::(1) executing dry-run sanity-check
|
||||
bootstrap::(2) executing actual run
|
||||
Checking stage0 library artifacts (x86_64-unknown-linux-gnu)
|
||||
Finished `release` profile [optimized + debuginfo] target(s) in 0.04s
|
||||
Checking stage0 compiler artifacts {rustc-main, rustc_abi, rustc_arena, rustc_ast, rustc_ast_ir, rustc_ast_lowering, rustc_ast_passes, rustc_ast_pretty, rustc_attr_data_structures, rustc_attr_parsing, rustc_baked_icu_data, rustc_borrowck, rustc_builtin_macros, rustc_codegen_llvm, rustc_codegen_ssa, rustc_const_eval, rustc_data_structures, rustc_driver, rustc_driver_impl, rustc_error_codes, rustc_error_messages, rustc_errors, rustc_expand, rustc_feature, rustc_fluent_macro, rustc_fs_util, rustc_graphviz, rustc_hir, rustc_hir_analysis, rustc_hir_pretty, rustc_hir_typeck, rustc_incremental, rustc_index, rustc_index_macros, rustc_infer, rustc_interface, rustc_lexer, rustc_lint, rustc_lint_defs, rustc_llvm, rustc_log, rustc_macros, rustc_metadata, rustc_middle, rustc_mir_build, rustc_mir_dataflow, rustc_mir_transform, rustc_monomorphize, rustc_next_trait_solver, rustc_parse, rustc_parse_format, rustc_passes, rustc_pattern_analysis, rustc_privacy, rustc_query_impl, rustc_query_system, rustc_resolve, rustc_sanitizers, rustc_serialize, rustc_session, rustc_smir, rustc_span, rustc_symbol_mangling, rustc_target, rustc_trait_selection, rustc_traits, rustc_transmute, rustc_ty_utils, rustc_type_ir, rustc_type_ir_macros, stable_mir} (x86_64-unknown-linux-gnu)
|
||||
Finished `release` profile [optimized + debuginfo] target(s) in 0.23s
|
||||
Checking stage0 bootstrap artifacts (x86_64-unknown-linux-gnu)
|
||||
Checking bootstrap v0.0.0 (/home/joe/repos/rust/src/bootstrap)
|
||||
Finished `release` profile [optimized + debuginfo] target(s) in 0.64s
|
||||
DEBUG bootstrap checking for postponed test failures from `test --no-fail-fast`
|
||||
Build completed successfully in 0:00:08
|
||||
```
|
||||
|
||||
[^experimental]: This shows what's *possible* with the infra in an experimental implementation.
|
||||
#### Controlling log output
|
||||
|
||||
The env var `BOOTSTRAP_TRACING` accepts a [`tracing` env-filter][tracing-env-filter]. The `TRACE` filter will enable *all* `trace` level or less verbose level tracing output.
|
||||
The env var `BOOTSTRAP_TRACING` accepts a [`tracing` env-filter][tracing-env-filter].
|
||||
|
||||
There are two orthogonal ways to control which kind of logs you want:
|
||||
|
||||
1. You can specify the log **level**, e.g. `DEBUG` or `TRACE`.
|
||||
2. You can also control the log **target**, e.g. `bootstrap` or `bootstrap::core::config` vs custom targets like `CONFIG_HANDLING`.
|
||||
- Custom targets are used to limit what is output when `BOOTSTRAP_TRACING=bootstrap=TRACE` is used, as they can be too verbose even for `TRACE` level by default. Currently used custom targets:
|
||||
- `CONFIG_HANDLING`
|
||||
|
||||
The `TRACE` filter will enable *all* `trace` level or less verbose level tracing output.
|
||||
|
||||
You can of course combine them (custom target logs are typically gated behind `TRACE` log level additionally):
|
||||
|
||||
```bash
|
||||
$ BOOTSTRAP_TRACING=CONFIG_HANDLING=TRACE ./x build library --stage 1
|
||||
```
|
||||
|
||||
[^unstable]: This output is always subject to further changes.
|
||||
|
||||
[tracing-env-filter]: https://docs.rs/tracing-subscriber/0.3.19/tracing_subscriber/filter/struct.EnvFilter.html
|
||||
|
||||
|
|
@ -73,28 +121,6 @@ For `#[instrument]`, it's recommended to:
|
|||
- Explicitly pick an instrumentation name via `name = ".."` to distinguish between e.g. `run` of different steps.
|
||||
- Take care to not cause diverging behavior via tracing, e.g. building extra things only when tracing infra is enabled.
|
||||
|
||||
### Enabling `tracing` bootstrap feature in rust-analyzer
|
||||
### rust-analyzer integration?
|
||||
|
||||
You can adjust your `settings.json`'s `rust-analyzer.check.overrideCommand` and `rust-analyzer.cargo.buildScripts.overrideCommand` if you want to also enable `logging` cargo feature by default in your editor. This is mostly useful if you want proper r-a completions and such when working on bootstrap itself.
|
||||
|
||||
```json
|
||||
"rust-analyzer.check.overrideCommand": [
|
||||
"BOOTSTRAP_TRACING=1", // <- BOOTSTRAP_TRACING=1 won't enable tracing filter, but it will activate bootstrap's `tracing` feature
|
||||
"python3",
|
||||
"x.py",
|
||||
"check",
|
||||
"--json-output",
|
||||
"--build-dir=build-rust-analyzer"
|
||||
],
|
||||
```
|
||||
|
||||
```json
|
||||
"rust-analyzer.cargo.buildScripts.overrideCommand": [
|
||||
"BOOTSTRAP_TRACING=1", // <- note this
|
||||
"python3",
|
||||
"x.py",
|
||||
"check",
|
||||
"--json-output",
|
||||
"--build-dir=build-rust-analyzer"
|
||||
],
|
||||
```
|
||||
Unfortunately, because bootstrap is a `rust-analyzer.linkedProjects`, you can't ask r-a to check/build bootstrap itself with `tracing` feature enabled to get relevant completions, due to lack of support as described in <https://github.com/rust-lang/rust-analyzer/issues/8521>.
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 137 KiB |
|
|
@ -1,4 +1,4 @@
|
|||
This file offers some tips on the coding conventions for rustc. This
|
||||
This file offers some tips on the coding conventions for rustc. This
|
||||
chapter covers [formatting](#formatting), [coding for correctness](#cc),
|
||||
[using crates from crates.io](#cio), and some tips on
|
||||
[structuring your PR for easy review](#er).
|
||||
|
|
@ -25,6 +25,7 @@ pass the <!-- date-check: nov 2022 --> `--edition=2021` argument yourself when c
|
|||
`rustfmt` directly.
|
||||
|
||||
[fmt]: https://github.com/rust-dev-tools/fmt-rfcs
|
||||
|
||||
[`rustfmt`]:https://github.com/rust-lang/rustfmt
|
||||
|
||||
## Formatting C++ code
|
||||
|
|
@ -40,6 +41,26 @@ When modifying that code, use this command to format it:
|
|||
This uses a pinned version of `clang-format`, to avoid relying on the local
|
||||
environment.
|
||||
|
||||
## Formatting and linting Python code
|
||||
|
||||
The Rust repository contains quite a lof of Python code. We try to keep
|
||||
it both linted and formatted by the [ruff][ruff] tool.
|
||||
|
||||
When modifying Python code, use this command to format it:
|
||||
```sh
|
||||
./x test tidy --extra-checks=py:fmt --bless
|
||||
```
|
||||
|
||||
and the following command to run lints:
|
||||
```sh
|
||||
./x test tidy --extra-checks=py:lint
|
||||
```
|
||||
|
||||
This uses a pinned version of `ruff`, to avoid relying on the local
|
||||
environment.
|
||||
|
||||
[ruff]: https://github.com/astral-sh/ruff
|
||||
|
||||
<a id="copyright"></a>
|
||||
|
||||
<!-- REUSE-IgnoreStart -->
|
||||
|
|
@ -84,7 +105,7 @@ Using `_` in a match is convenient, but it means that when new
|
|||
variants are added to the enum, they may not get handled correctly.
|
||||
Ask yourself: if a new variant were added to this enum, what's the
|
||||
chance that it would want to use the `_` code, versus having some
|
||||
other treatment? Unless the answer is "low", then prefer an
|
||||
other treatment? Unless the answer is "low", then prefer an
|
||||
exhaustive match. (The same advice applies to `if let` and `while
|
||||
let`, which are effectively tests for a single variant.)
|
||||
|
||||
|
|
@ -124,7 +145,7 @@ See the [crates.io dependencies][crates] section.
|
|||
# How to structure your PR
|
||||
|
||||
How you prepare the commits in your PR can make a big difference for the
|
||||
reviewer. Here are some tips.
|
||||
reviewer. Here are some tips.
|
||||
|
||||
**Isolate "pure refactorings" into their own commit.** For example, if
|
||||
you rename a method, then put that rename into its own commit, along
|
||||
|
|
@ -165,4 +186,5 @@ to the compiler.
|
|||
crate-related, often the spelling is changed to `krate`.
|
||||
|
||||
[tcx]: ./ty.md
|
||||
|
||||
[crates]: ./crates-io.md
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ The [`rustc_driver`] is essentially `rustc`'s `main` function.
|
|||
It acts as the glue for running the various phases of the compiler in the correct order,
|
||||
using the interface defined in the [`rustc_interface`] crate. Where possible, using [`rustc_driver`] rather than [`rustc_interface`] is recommended.
|
||||
|
||||
The main entry point of [`rustc_driver`] is [`rustc_driver::RunCompiler`][rd_rc].
|
||||
The main entry point of [`rustc_driver`] is [`rustc_driver::run_compiler`][rd_rc].
|
||||
This builder accepts the same command-line args as rustc as well as an implementation of [`Callbacks`][cb] and a couple of other optional options.
|
||||
[`Callbacks`][cb] is a `trait` that allows for custom compiler configuration,
|
||||
as well as allowing custom code to run after different phases of the compilation.
|
||||
|
|
@ -40,7 +40,7 @@ specifically [`rustc_driver_impl::run_compiler`][rdi_rc]
|
|||
[cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html
|
||||
[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-interface-example.rs
|
||||
[i_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/fn.run_compiler.html
|
||||
[rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/struct.RunCompiler.html
|
||||
[rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html
|
||||
[rdi_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver_impl/fn.run_compiler.html
|
||||
[stupid-stats]: https://github.com/nrc/stupid-stats
|
||||
[`nightly-rustc`]: https://doc.rust-lang.org/nightly/nightly-rustc/
|
||||
|
|
|
|||
|
|
@ -34,7 +34,8 @@ Previously, due to a [rustc bug], stable items inside unstable modules were
|
|||
available to stable code in that location.
|
||||
As of <!-- date-check --> September 2024, items with [accidentally stabilized
|
||||
paths] are marked with the `#[rustc_allowed_through_unstable_modules]` attribute
|
||||
to prevent code dependent on those paths from breaking.
|
||||
to prevent code dependent on those paths from breaking. Do *not* add this attribute
|
||||
to any more items unless that is needed to avoid breaking changes.
|
||||
|
||||
The `unstable` attribute may also have the `soft` value, which makes it a
|
||||
future-incompatible deny-by-default lint instead of a hard error. This is used
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ for more details.
|
|||
| Directive | Explanation | Supported test suites | Possible values |
|
||||
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------|----------------------------------------------|-----------------------------------------------------------------------------------------|
|
||||
| `check-run-results` | Check run test binary `run-{pass,fail}` output snapshot | `ui`, `crashes`, `incremental` if `run-pass` | N/A |
|
||||
| `error-pattern` | Check that output contains a specific string | `ui`, `crashes`, `incremental` if `run-pass` | String |
|
||||
| `error-pattern` | Check that output contains a specific string | `ui`, `crashes`, `incremental` if `run-pass` | String |
|
||||
| `regex-error-pattern` | Check that output contains a regex pattern | `ui`, `crashes`, `incremental` if `run-pass` | Regex |
|
||||
| `check-stdout` | Check `stdout` against `error-pattern`s from running test binary[^check_stdout] | `ui`, `crashes`, `incremental` | N/A |
|
||||
| `normalize-stderr-32bit` | Normalize actual stderr (for 32-bit platforms) with a rule `"<raw>" -> "<normalized>"` before comparing against snapshot | `ui`, `incremental` | `"<RAW>" -> "<NORMALIZED>"`, `<RAW>`/`<NORMALIZED>` is regex capture and replace syntax |
|
||||
|
|
@ -152,6 +152,8 @@ Some examples of `X` in `ignore-X` or `only-X`:
|
|||
`compare-mode-split-dwarf`, `compare-mode-split-dwarf-single`
|
||||
- The two different test modes used by coverage tests:
|
||||
`ignore-coverage-map`, `ignore-coverage-run`
|
||||
- When testing a dist toolchain: `dist`
|
||||
- This needs to be enabled with `COMPILETEST_ENABLE_DIST_TESTS=1`
|
||||
|
||||
The following directives will check rustc build settings and target
|
||||
settings:
|
||||
|
|
@ -174,6 +176,7 @@ settings:
|
|||
- `needs-rust-lld` — ignores if the rust lld support is not enabled (`rust.lld =
|
||||
true` in `config.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
|
||||
the case on Windows if the developer did not enable privileged symlink
|
||||
permissions.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue