From 9aa572d598b066fdf9e5a0ff72891288d87d006c Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Thu, 22 May 2025 14:43:42 +0200 Subject: use consistent title capitalization --- src/doc/rustc-dev-guide/src/SUMMARY.md | 18 +++++++++--------- .../src/backend/implicit-caller-location.md | 12 ++++++------ .../rustc-dev-guide/src/backend/libs-and-metadata.md | 2 +- .../src/llvm-coverage-instrumentation.md | 2 +- src/doc/rustc-dev-guide/src/part-5-intro.md | 2 +- src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md | 2 +- .../rustc-dev-guide/src/profile-guided-optimization.md | 16 ++++++++-------- src/doc/rustc-dev-guide/src/sanitizers.md | 2 +- 8 files changed, 28 insertions(+), 28 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index a7b76233d19..60f3bf28782 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/src/SUMMARY.md @@ -181,7 +181,7 @@ - [Significant changes and quirks](./solve/significant-changes.md) - [`Unsize` and `CoerceUnsized` traits](./traits/unsize.md) - [Type checking](./type-checking.md) - - [Method Lookup](./method-lookup.md) + - [Method lookup](./method-lookup.md) - [Variance](./variance.md) - [Coherence checking](./coherence.md) - [Opaque types](./opaque-types-type-alias-impl-trait.md) @@ -189,7 +189,7 @@ - [Return Position Impl Trait In Trait](./return-position-impl-trait-in-trait.md) - [Region inference restrictions][opaque-infer] - [Const condition checking](./effects.md) -- [Pattern and Exhaustiveness Checking](./pat-exhaustive-checking.md) +- [Pattern and exhaustiveness checking](./pat-exhaustive-checking.md) - [Unsafety checking](./unsafety-checking.md) - [MIR dataflow](./mir/dataflow.md) - [Drop elaboration](./mir/drop-elaboration.md) @@ -209,7 +209,7 @@ - [Closure capture inference](./closure.md) - [Async closures/"coroutine-closures"](coroutine-closures.md) -# MIR to Binaries +# MIR to binaries - [Prologue](./part-5-intro.md) - [MIR optimizations](./mir/optimizations.md) @@ -218,15 +218,15 @@ - [Interpreter](./const-eval/interpret.md) - [Monomorphization](./backend/monomorph.md) - [Lowering MIR](./backend/lowering-mir.md) -- [Code Generation](./backend/codegen.md) +- [Code generation](./backend/codegen.md) - [Updating LLVM](./backend/updating-llvm.md) - [Debugging LLVM](./backend/debugging.md) - [Backend Agnostic Codegen](./backend/backend-agnostic.md) - - [Implicit Caller Location](./backend/implicit-caller-location.md) -- [Libraries and Metadata](./backend/libs-and-metadata.md) -- [Profile-guided Optimization](./profile-guided-optimization.md) -- [LLVM Source-Based Code Coverage](./llvm-coverage-instrumentation.md) -- [Sanitizers Support](./sanitizers.md) + - [Implicit caller location](./backend/implicit-caller-location.md) +- [Libraries and metadata](./backend/libs-and-metadata.md) +- [Profile-guided optimization](./profile-guided-optimization.md) +- [LLVM source-based code coverage](./llvm-coverage-instrumentation.md) +- [Sanitizers support](./sanitizers.md) - [Debugging support in the Rust compiler](./debugging-support-in-rustc.md) --- diff --git a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md index 17158497d59..c5ee00813a3 100644 --- a/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md +++ b/src/doc/rustc-dev-guide/src/backend/implicit-caller-location.md @@ -1,4 +1,4 @@ -# Implicit Caller Location +# Implicit caller location @@ -8,7 +8,7 @@ adds the [`#[track_caller]`][attr-reference] attribute for functions, the [`caller_location`][intrinsic] intrinsic, and the stabilization-friendly [`core::panic::Location::caller`][wrapper] wrapper. -## Motivating Example +## Motivating example Take this example program: @@ -39,7 +39,7 @@ These error messages are achieved through a combination of changes to `panic!` i of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. -## Reading Caller Location +## Reading caller location Previously, `panic!` made use of the `file!()`, `line!()`, and `column!()` macros to construct a [`Location`] pointing to where the panic occurred. These macros couldn't be given an overridden @@ -51,7 +51,7 @@ was expanded. This function is itself annotated with `#[track_caller]` and wraps [`caller_location`][intrinsic] compiler intrinsic implemented by rustc. This intrinsic is easiest explained in terms of how it works in a `const` context. -## Caller Location in `const` +## Caller location in `const` There are two main phases to returning the caller location in a const context: walking up the stack to find the right location and allocating a const value to return. @@ -138,7 +138,7 @@ fn main() { } ``` -### Dynamic Dispatch +### Dynamic dispatch In codegen contexts we have to modify the callee ABI to pass this information down the stack, but the attribute expressly does *not* modify the type of the function. The ABI change must be @@ -156,7 +156,7 @@ probably the best we can do without modifying fully-stabilized type signatures. > whether we'll be called in a const context (safe to ignore shim) or in a codegen context (unsafe > to ignore shim). Even if we did know, the results from const and codegen contexts must agree. -## The Attribute +## The attribute The `#[track_caller]` attribute is checked alongside other codegen attributes to ensure the function: diff --git a/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md b/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md index eeb2af5e6bc..aa1d644703a 100644 --- a/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md +++ b/src/doc/rustc-dev-guide/src/backend/libs-and-metadata.md @@ -1,4 +1,4 @@ -# Libraries and Metadata +# Libraries and metadata When the compiler sees a reference to an external crate, it needs to load some information about that crate. This chapter gives an overview of that process, diff --git a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md index 6bc21b6deeb..28e0e7a908d 100644 --- a/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md +++ b/src/doc/rustc-dev-guide/src/llvm-coverage-instrumentation.md @@ -1,4 +1,4 @@ -# LLVM Source-Based Code Coverage +# LLVM source-based code coverage diff --git a/src/doc/rustc-dev-guide/src/part-5-intro.md b/src/doc/rustc-dev-guide/src/part-5-intro.md index f32508d2774..a44fff1e143 100644 --- a/src/doc/rustc-dev-guide/src/part-5-intro.md +++ b/src/doc/rustc-dev-guide/src/part-5-intro.md @@ -1,4 +1,4 @@ -# From MIR to Binaries +# From MIR to binaries All of the preceding chapters of this guide have one thing in common: we never generated any executable machine code at all! diff --git a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md b/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md index 4a796ac9500..e953931aa78 100644 --- a/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md +++ b/src/doc/rustc-dev-guide/src/pat-exhaustive-checking.md @@ -1,4 +1,4 @@ -# Pattern and Exhaustiveness Checking +# Pattern and exhaustiveness checking In Rust, pattern matching and bindings have a few very helpful properties. The compiler will check that bindings are irrefutable when made and that match arms diff --git a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md index 39bc8b5e862..d279786ac45 100644 --- a/src/doc/rustc-dev-guide/src/profile-guided-optimization.md +++ b/src/doc/rustc-dev-guide/src/profile-guided-optimization.md @@ -1,4 +1,4 @@ -# Profile Guided Optimization +# Profile-guided optimization @@ -6,7 +6,7 @@ This chapter describes what PGO is and how the support for it is implemented in `rustc`. -## What Is Profiled-Guided Optimization? +## What is profiled-guided optimization? The basic concept of PGO is to collect data about the typical execution of a program (e.g. which branches it is likely to take) and then use this data @@ -52,7 +52,7 @@ instrumentation, via the experimental option [`-C instrument-coverage`](./llvm-coverage-instrumentation.md), but using these coverage results for PGO has not been attempted at this time. -### Overall Workflow +### Overall workflow Generating a PGO-optimized program involves the following four steps: @@ -62,12 +62,12 @@ Generating a PGO-optimized program involves the following four steps: 4. Compile the program again, this time making use of the profiling data (e.g. `rustc -C profile-use=merged.profdata main.rs`) -### Compile-Time Aspects +### Compile-time aspects Depending on which step in the above workflow we are in, two different things can happen at compile time: -#### Create Binaries with Instrumentation +#### Create binaries with instrumentation As mentioned above, the profiling instrumentation is added by LLVM. `rustc` instructs LLVM to do so [by setting the appropriate][pgo-gen-passmanager] @@ -88,7 +88,7 @@ runtime are not removed [by marking the with the right export level][pgo-gen-sym [pgo-gen-symbols]:https://github.com/rust-lang/rust/blob/1.34.1/src/librustc_codegen_ssa/back/symbol_export.rs#L212-L225 -#### Compile Binaries Where Optimizations Make Use Of Profiling Data +#### Compile binaries where optimizations make use of profiling data In the final step of the workflow described above, the program is compiled again, with the compiler using the gathered profiling data in order to drive @@ -106,7 +106,7 @@ LLVM does the rest (e.g. setting branch weights, marking functions with `cold` or `inlinehint`, etc). -### Runtime Aspects +### Runtime aspects Instrumentation-based approaches always also have a runtime component, i.e. once we have an instrumented program, that program needs to be run in order @@ -134,7 +134,7 @@ instrumentation artifacts show up in LLVM IR. [rmake-tests]: https://github.com/rust-lang/rust/tree/master/tests/run-make [codegen-test]: https://github.com/rust-lang/rust/blob/master/tests/codegen/pgo-instrumentation.rs -## Additional Information +## Additional information Clang's documentation contains a good overview on [PGO in LLVM][llvm-pgo]. diff --git a/src/doc/rustc-dev-guide/src/sanitizers.md b/src/doc/rustc-dev-guide/src/sanitizers.md index b1654b15e08..664b4feac4f 100644 --- a/src/doc/rustc-dev-guide/src/sanitizers.md +++ b/src/doc/rustc-dev-guide/src/sanitizers.md @@ -1,4 +1,4 @@ -# Sanitizers Support +# Sanitizers support The rustc compiler contains support for following sanitizers: -- cgit 1.4.1-3-g733a5 From a4c8ef9f341217b103dfd4d0d9d9a641cda6ef4c Mon Sep 17 00:00:00 2001 From: xizheyin Date: Fri, 13 Jun 2025 22:32:33 +0800 Subject: Adjust some doc for Query System Signed-off-by: xizheyin --- src/doc/rustc-dev-guide/src/query.md | 85 +++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 39 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 782c5b4b3c0..0c8e136b381 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/src/query.md @@ -67,9 +67,15 @@ are cheaply cloneable; insert an `Rc` if necessary). ### Providers If, however, the query is *not* in the cache, then the compiler will -try to find a suitable **provider**. A provider is a function that has -been defined and linked into the compiler somewhere that contains the -code to compute the result of the query. +call the corresponding **provider** function. A provider is a function +implemented in a specific module and **manually registered** into the +[`Providers`][providers_struct] struct during compiler initialization. +The macro system generates the [`Providers`][providers_struct] struct, +which acts as a function table for all query implementations, where each +field is a function pointer to the actual provider. + +**Note:** The `Providers` struct is generated by macros and acts as a function table for all query implementations. +It is **not** a Rust trait, but a plain struct with function pointer fields. **Providers are defined per-crate.** The compiler maintains, internally, a table of providers for every crate, at least @@ -97,7 +103,18 @@ fn provider<'tcx>( Providers take two arguments: the `tcx` and the query key. They return the result of the query. -### How providers are setup +N.B. Most of the `rustc_*` crates only provide **local +providers**. Almost all **extern providers** wind up going through the +[`rustc_metadata` crate][rustc_metadata], which loads the information +from the crate metadata. But in some cases there are crates that +provide queries for *both* local and external crates, in which case +they define both a `provide` and a `provide_extern` function, through +[`wasm_import_module_map`][wasm_import_module_map], that `rustc_driver` can invoke. + +[rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html +[wasm_import_module_map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/back/symbol_export/fn.wasm_import_module_map.html + +### How providers are set up When the tcx is created, it is given the providers by its creator using the [`Providers`][providers_struct] struct. This struct is generated by @@ -108,19 +125,16 @@ the macros here, but it is basically a big list of function pointers: ```rust,ignore struct Providers { type_of: for<'tcx> fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>, - ... + // ... one field for each query } ``` -At present, we have one copy of the struct for local crates, and one -for external crates, though the plan is that we may eventually have -one per crate. +#### How are providers registered? + +The `Providers` struct is filled in during compiler initialization, mainly by the `rustc_driver` crate. +But the actual provider functions are implemented in various `rustc_*` crates (like `rustc_middle`, `rustc_hir_analysis`, etc). -These `Providers` structs are ultimately created and populated by -`rustc_driver`, but it does this by distributing the work -throughout the other `rustc_*` crates. This is done by invoking -various [`provide`][provide_fn] functions. These functions tend to look -something like this: +To register providers, each crate exposes a [`provide`][provide_fn] function that looks like this: [provide_fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/fn.provide.html @@ -128,41 +142,34 @@ something like this: pub fn provide(providers: &mut Providers) { *providers = Providers { type_of, + // ... add more providers here ..*providers }; } ``` -That is, they take an `&mut Providers` and mutate it in place. Usually -we use the formulation above just because it looks nice, but you could -as well do `providers.type_of = type_of`, which would be equivalent. -(Here, `type_of` would be a top-level function, defined as we saw -before.) So, if we want to add a provider for some other query, -let's call it `fubar`, into the crate above, we might modify the `provide()` -function like so: +- This function takes a mutable reference to the `Providers` struct and sets the fields to point to the correct provider functions. +- You can also assign fields individually, e.g. `providers.type_of = type_of;`. -```rust,ignore -pub fn provide(providers: &mut Providers) { - *providers = Providers { - type_of, - fubar, - ..*providers - }; -} +#### Adding a new provider -fn fubar<'tcx>(tcx: TyCtxt<'tcx>, key: DefId) -> Fubar<'tcx> { ... } -``` +Suppose you want to add a new query called `fubar`. You would: -N.B. Most of the `rustc_*` crates only provide **local -providers**. Almost all **extern providers** wind up going through the -[`rustc_metadata` crate][rustc_metadata], which loads the information -from the crate metadata. But in some cases there are crates that -provide queries for *both* local and external crates, in which case -they define both a `provide` and a `provide_extern` function, through -[`wasm_import_module_map`][wasm_import_module_map], that `rustc_driver` can invoke. +1. Implement the provider function: + ```rust,ignore + fn fubar<'tcx>(tcx: TyCtxt<'tcx>, key: DefId) -> Fubar<'tcx> { ... } + ``` +2. Register it in the `provide` function: + ```rust,ignore + pub fn provide(providers: &mut Providers) { + *providers = Providers { + fubar, + ..*providers + }; + } + ``` -[rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html -[wasm_import_module_map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/back/symbol_export/fn.wasm_import_module_map.html +--- ## Adding a new query -- cgit 1.4.1-3-g733a5 From a70deb6e75437f3a2101d413b74a3ab5dff55181 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 14 Jun 2025 22:16:51 +0200 Subject: content has moved to another chapter --- src/doc/rustc-dev-guide/src/query.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 0c8e136b381..9255c4fa4a5 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/src/query.md @@ -2,7 +2,7 @@ -As described in [the high-level overview of the compiler][hl], the Rust compiler +As described in [Overview of the compiler], the Rust compiler is still (as of July 2021) transitioning from a traditional "pass-based" setup to a "demand-driven" system. The compiler query system is the key to rustc's demand-driven organization. @@ -13,7 +13,7 @@ there is a query called `type_of` that, given the [`DefId`] of some item, will compute the type of that item and return it to you. [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/def_id/struct.DefId.html -[hl]: ./compiler-src.md +[Overview of the compiler]: overview.md#queries Query execution is *memoized*. The first time you invoke a query, it will go do the computation, but the next time, the result is -- cgit 1.4.1-3-g733a5 From 0834e48a11f3467426e4c8ac29969f5c9c7d1e42 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 14 Jun 2025 22:44:47 +0200 Subject: use sentence case --- .../queries/incremental-compilation-in-detail.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md index 03c822d4fee..18e0e25c531 100644 --- a/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md +++ b/src/doc/rustc-dev-guide/src/queries/incremental-compilation-in-detail.md @@ -1,4 +1,4 @@ -# Incremental Compilation in detail +# Incremental compilation in detail @@ -66,7 +66,7 @@ because it reads the up-to-date version of `Hir(bar)`. Also, we re-run `type_check_item(bar)` because result of `type_of(bar)` might have changed. -## The Problem With The Basic Algorithm: False Positives +## The problem with the basic algorithm: false positives If you read the previous paragraph carefully you'll notice that it says that `type_of(bar)` *might* have changed because one of its inputs has changed. @@ -93,7 +93,7 @@ of examples like this and small changes to the input often potentially affect very large parts of the output binaries. As a consequence, we had to make the change detection system smarter and more accurate. -## Improving Accuracy: The red-green Algorithm +## Improving accuracy: the red-green algorithm The "false positives" problem can be solved by interleaving change detection and query re-evaluation. Instead of walking the graph all the way to the @@ -191,7 +191,7 @@ then itself involve recursively invoking more queries, which can mean we come ba to the `try_mark_green()` algorithm for the dependencies recursively. -## The Real World: How Persistence Makes Everything Complicated +## The real world: how persistence makes everything complicated The sections above described the underlying algorithm for incremental compilation but because the compiler process exits after being finished and @@ -258,7 +258,7 @@ the `LocalId`s within it are still the same. -### Checking Query Results For Changes: HashStable And Fingerprints +### Checking query results for changes: `HashStable` and `Fingerprint`s In order to do red-green-marking we often need to check if the result of a query has changed compared to the result it had during the previous @@ -306,7 +306,7 @@ This approach works rather well but it's not without flaws: their stable equivalents while doing the hashing. -### A Tale Of Two DepGraphs: The Old And The New +### A tale of two `DepGraph`s: the old and the new The initial description of dependency tracking glosses over a few details that quickly become a head scratcher when actually trying to implement things. @@ -344,7 +344,7 @@ new graph is serialized out to disk, alongside the query result cache, and can act as the previous dep-graph in a subsequent compilation session. -### Didn't You Forget Something?: Cache Promotion +### Didn't you forget something?: cache promotion The system described so far has a somewhat subtle property: If all inputs of a dep-node are green then the dep-node itself can be marked as green without @@ -374,7 +374,7 @@ the result cache doesn't unnecessarily shrink again. -# Incremental Compilation and the Compiler Backend +# Incremental compilation and the compiler backend The compiler backend, the part involving LLVM, is using the query system but it is not implemented in terms of queries itself. As a consequence it does not @@ -406,7 +406,7 @@ would save. -## Query Modifiers +## Query modifiers The query system allows for applying [modifiers][mod] to queries. These modifiers affect certain aspects of how the system treats the query with @@ -472,7 +472,7 @@ respect to incremental compilation: [mod]: ../query.html#adding-a-new-kind-of-query -## The Projection Query Pattern +## The projection query pattern It's interesting to note that `eval_always` and `no_hash` can be used together in the so-called "projection query" pattern. It is often the case that there is @@ -516,7 +516,7 @@ because we have the projections to take care of keeping things green as much as possible. -# Shortcomings of the Current System +# Shortcomings of the current system There are many things that still can be improved. -- cgit 1.4.1-3-g733a5 From 820e88a7c6be0058da6f71e2fe0d468608333322 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 14 Jun 2025 22:49:46 +0200 Subject: title case --- src/doc/rustc-dev-guide/src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 9255c4fa4a5..581d31966cd 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/src/query.md @@ -39,7 +39,7 @@ will in turn demand information about that crate, starting from the Although this vision is not fully realized, large sections of the compiler (for example, generating [MIR](./mir/index.md)) currently work exactly like this. -[^incr-comp-detail]: The ["Incremental Compilation in Detail](queries/incremental-compilation-in-detail.md) chapter gives a more +[^incr-comp-detail]: The ["Incremental compilation in detail](queries/incremental-compilation-in-detail.md) chapter gives a more in-depth description of what queries are and how they work. If you intend to write a query of your own, this is a good read. -- cgit 1.4.1-3-g733a5 From 21a1e51704ec18a0ed89a737fcf01a44567ce393 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 14 Jun 2025 22:56:10 +0200 Subject: do not inline links --- src/doc/rustc-dev-guide/src/query.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md index 581d31966cd..0ca1b360a70 100644 --- a/src/doc/rustc-dev-guide/src/query.md +++ b/src/doc/rustc-dev-guide/src/query.md @@ -37,12 +37,15 @@ will in turn demand information about that crate, starting from the actual parsing. Although this vision is not fully realized, large sections of the -compiler (for example, generating [MIR](./mir/index.md)) currently work exactly like this. +compiler (for example, generating [MIR]) currently work exactly like this. -[^incr-comp-detail]: The ["Incremental compilation in detail](queries/incremental-compilation-in-detail.md) chapter gives a more +[^incr-comp-detail]: The [Incremental compilation in detail] chapter gives a more in-depth description of what queries are and how they work. If you intend to write a query of your own, this is a good read. +[Incremental compilation in detail]: queries/incremental-compilation-in-detail.md +[MIR]: mir/index.md + ## Invoking queries Invoking a query is simple. The [`TyCtxt`] ("type context") struct offers a method -- cgit 1.4.1-3-g733a5 From 808d16c536845fdbae31825d7c7e05ef47b82358 Mon Sep 17 00:00:00 2001 From: Alice Ryhl Date: Mon, 16 Jun 2025 17:03:33 +0200 Subject: Use stage 1 for building docs --- src/doc/rustc-dev-guide/src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 0575de642ee..46d74b96734 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/src/contributing.md @@ -364,7 +364,7 @@ To find documentation-related issues, use the [A-docs label]. You can find documentation style guidelines in [RFC 1574]. -To build the standard library documentation, use `x doc --stage 0 library --open`. +To build the standard library documentation, use `x doc --stage 1 library --open`. To build the documentation for a book (e.g. the unstable book), use `x doc src/doc/unstable-book.` Results should appear in `build/host/doc`, as well as automatically open in your default browser. See [Building Documentation](./building/compiler-documenting.md#building-documentation) for more -- cgit 1.4.1-3-g733a5 From 1dbf86a631f3f1394e27d8be66139466428f968e Mon Sep 17 00:00:00 2001 From: Chris Bloodsworth Date: Mon, 16 Jun 2025 16:08:21 -0400 Subject: Remove hanging parenthesis from example signature. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Also replaced '→' symbol with '->' for consistency across the table. --- src/doc/rustc-dev-guide/src/ty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/ty.md b/src/doc/rustc-dev-guide/src/ty.md index ce6cffec1ad..767ac3fdba2 100644 --- a/src/doc/rustc-dev-guide/src/ty.md +++ b/src/doc/rustc-dev-guide/src/ty.md @@ -62,8 +62,8 @@ Here is a summary: | Describe the *syntax* of a type: what the user wrote (with some desugaring). | Describe the *semantics* of a type: the meaning of what the user wrote. | | Each `rustc_hir::Ty` has its own spans corresponding to the appropriate place in the program. | Doesn’t correspond to a single place in the user’s program. | | `rustc_hir::Ty` has generics and lifetimes; however, some of those lifetimes are special markers like [`LifetimeKind::Implicit`][implicit]. | `ty::Ty` has the full type, including generics and lifetimes, even if the user left them out | -| `fn foo(x: u32) → u32 { }` - Two `rustc_hir::Ty` representing each usage of `u32`, each has its own `Span`s, and `rustc_hir::Ty` doesn’t tell us that both are the same type | `fn foo(x: u32) → u32 { }` - One `ty::Ty` for all instances of `u32` throughout the program, and `ty::Ty` tells us that both usages of `u32` mean the same type. | -| `fn foo(x: &u32) -> &u32)` - Two `rustc_hir::Ty` again. Lifetimes for the references show up in the `rustc_hir::Ty`s using a special marker, [`LifetimeKind::Implicit`][implicit]. | `fn foo(x: &u32) -> &u32)`- A single `ty::Ty`. The `ty::Ty` has the hidden lifetime param. | +| `fn foo(x: u32) -> u32 { }` - Two `rustc_hir::Ty` representing each usage of `u32`, each has its own `Span`s, and `rustc_hir::Ty` doesn’t tell us that both are the same type | `fn foo(x: u32) -> u32 { }` - One `ty::Ty` for all instances of `u32` throughout the program, and `ty::Ty` tells us that both usages of `u32` mean the same type. | +| `fn foo(x: &u32) -> &u32 { }` - Two `rustc_hir::Ty` again. Lifetimes for the references show up in the `rustc_hir::Ty`s using a special marker, [`LifetimeKind::Implicit`][implicit]. | `fn foo(x: &u32) -> &u32 { }`- A single `ty::Ty`. The `ty::Ty` has the hidden lifetime param. | [implicit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.LifetimeKind.html#variant.Implicit -- cgit 1.4.1-3-g733a5 From 8bc55da22eb6e5d09d56817ecc94031730c166ff Mon Sep 17 00:00:00 2001 From: lolbinarycat Date: Tue, 17 Jun 2025 11:31:04 -0500 Subject: Profiling with perf: specify the section of bootstrap settings. --- src/doc/rustc-dev-guide/src/profiling/with_perf.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/profiling/with_perf.md b/src/doc/rustc-dev-guide/src/profiling/with_perf.md index 742ea1c41a6..0d4f23bcd9a 100644 --- a/src/doc/rustc-dev-guide/src/profiling/with_perf.md +++ b/src/doc/rustc-dev-guide/src/profiling/with_perf.md @@ -7,8 +7,8 @@ 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 `bootstrap.toml`: - - `debuginfo-level = 1` - enables line debuginfo - - `jemalloc = false` - lets you do memory use profiling with valgrind + - `rust.debuginfo-level = 1` - enables line debuginfo + - `rust.jemalloc = false` - lets you do memory use profiling with valgrind - leave everything else the defaults - Run `./x build` to get a full build - Make a rustup toolchain pointing to that result -- cgit 1.4.1-3-g733a5 From d96b2d4398f01dc2cfeb6cd7e2931157fb784a71 Mon Sep 17 00:00:00 2001 From: Boxy Date: Fri, 6 Jun 2025 20:20:06 +0100 Subject: Stub chapter and consolidate under `/hir/` --- src/doc/rustc-dev-guide/src/SUMMARY.md | 5 ++- src/doc/rustc-dev-guide/src/ast-lowering.md | 48 ---------------------- src/doc/rustc-dev-guide/src/diagnostics.md | 2 +- src/doc/rustc-dev-guide/src/hir-debugging.md | 15 ------- src/doc/rustc-dev-guide/src/hir.md | 2 +- .../src/hir/ambig-unambig-ty-and-consts.md | 1 + src/doc/rustc-dev-guide/src/hir/debugging.md | 15 +++++++ src/doc/rustc-dev-guide/src/hir/lowering.md | 48 ++++++++++++++++++++++ src/doc/rustc-dev-guide/src/overview.md | 2 +- 9 files changed, 70 insertions(+), 68 deletions(-) delete mode 100644 src/doc/rustc-dev-guide/src/ast-lowering.md delete mode 100644 src/doc/rustc-dev-guide/src/hir-debugging.md create mode 100644 src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md create mode 100644 src/doc/rustc-dev-guide/src/hir/debugging.md create mode 100644 src/doc/rustc-dev-guide/src/hir/lowering.md (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 2acc3c2199b..50a3f44add3 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/src/SUMMARY.md @@ -121,8 +121,9 @@ - [Feature gate checking](./feature-gate-ck.md) - [Lang Items](./lang-items.md) - [The HIR (High-level IR)](./hir.md) - - [Lowering AST to HIR](./ast-lowering.md) - - [Debugging](./hir-debugging.md) + - [Lowering AST to HIR](./hir/lowering.md) + - [Ambig/Unambig Types and Consts](./hir/ambig-unambig-ty-and-consts.md) + - [Debugging](./hir/debugging.md) - [The THIR (Typed High-level IR)](./thir.md) - [The MIR (Mid-level IR)](./mir/index.md) - [MIR construction](./mir/construction.md) diff --git a/src/doc/rustc-dev-guide/src/ast-lowering.md b/src/doc/rustc-dev-guide/src/ast-lowering.md deleted file mode 100644 index 033fd4b76f2..00000000000 --- a/src/doc/rustc-dev-guide/src/ast-lowering.md +++ /dev/null @@ -1,48 +0,0 @@ -# AST lowering - -The AST lowering step converts AST to [HIR](hir.html). -This means many structures are removed if they are irrelevant -for type analysis or similar syntax agnostic analyses. Examples -of such structures include but are not limited to - -* Parenthesis - * Removed without replacement, the tree structure makes order explicit -* `for` loops and `while (let)` loops - * Converted to `loop` + `match` and some `let` bindings -* `if let` - * Converted to `match` -* Universal `impl Trait` - * Converted to generic arguments - (but with some flags, to know that the user didn't write them) -* Existential `impl Trait` - * Converted to a virtual `existential type` declaration - -Lowering needs to uphold several invariants in order to not trigger the -sanity checks in `compiler/rustc_passes/src/hir_id_validator.rs`: - -1. A `HirId` must be used if created. So if you use the `lower_node_id`, - you *must* use the resulting `NodeId` or `HirId` (either is fine, since - any `NodeId`s in the `HIR` are checked for existing `HirId`s) -2. Lowering a `HirId` must be done in the scope of the *owning* item. - This means you need to use `with_hir_id_owner` if you are creating parts - of an item other than the one being currently lowered. This happens for - example during the lowering of existential `impl Trait` -3. A `NodeId` that will be placed into a HIR structure must be lowered, - even if its `HirId` is unused. Calling - `let _ = self.lower_node_id(node_id);` is perfectly legitimate. -4. If you are creating new nodes that didn't exist in the `AST`, you *must* - create new ids for them. This is done by calling the `next_id` method, - which produces both a new `NodeId` as well as automatically lowering it - for you so you also get the `HirId`. - -If you are creating new `DefId`s, since each `DefId` needs to have a -corresponding `NodeId`, it is advisable to add these `NodeId`s to the -`AST` so you don't have to generate new ones during lowering. This has -the advantage of creating a way to find the `DefId` of something via its -`NodeId`. If lowering needs this `DefId` in multiple places, you can't -generate a new `NodeId` in all those places because you'd also get a new -`DefId` then. With a `NodeId` from the `AST` this is not an issue. - -Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s -instead of lowering having to do it on the fly. Centralizing the `DefId` -generation in one place makes it easier to refactor and reason about. diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md index 01e59c91904..33f5441d36e 100644 --- a/src/doc/rustc-dev-guide/src/diagnostics.md +++ b/src/doc/rustc-dev-guide/src/diagnostics.md @@ -553,7 +553,7 @@ compiler](#linting-early-in-the-compiler). [AST nodes]: the-parser.md -[AST lowering]: ast-lowering.md +[AST lowering]: ./hir/lowering.md [HIR nodes]: hir.md [MIR nodes]: mir/index.md [macro expansion]: macro-expansion.md diff --git a/src/doc/rustc-dev-guide/src/hir-debugging.md b/src/doc/rustc-dev-guide/src/hir-debugging.md deleted file mode 100644 index 5a0bda20842..00000000000 --- a/src/doc/rustc-dev-guide/src/hir-debugging.md +++ /dev/null @@ -1,15 +0,0 @@ -# HIR Debugging - -Use the `-Z unpretty=hir` flag to produce a human-readable representation of the HIR. -For cargo projects this can be done with `cargo rustc -- -Z unpretty=hir`. -This output is useful when you need to see at a glance how your code was desugared and transformed -during AST lowering. - -For a full `Debug` dump of the data in the HIR, use the `-Z unpretty=hir-tree` flag. -This may be useful when you need to see the full structure of the HIR from the perspective of the -compiler. - -If you are trying to correlate `NodeId`s or `DefId`s with source code, the -`-Z unpretty=expanded,identified` flag may be useful. - -TODO: anything else? [#1159](https://github.com/rust-lang/rustc-dev-guide/issues/1159) diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md index 0c1c9941572..72fb1070157 100644 --- a/src/doc/rustc-dev-guide/src/hir.md +++ b/src/doc/rustc-dev-guide/src/hir.md @@ -5,7 +5,7 @@ The HIR – "High-Level Intermediate Representation" – is the primary IR used in most of rustc. It is a compiler-friendly representation of the abstract syntax tree (AST) that is generated after parsing, macro expansion, and name -resolution (see [Lowering](./ast-lowering.html) for how the HIR is created). +resolution (see [Lowering](./hir/lowering.md) for how the HIR is created). Many parts of HIR resemble Rust surface syntax quite closely, with the exception that some of Rust's expression forms have been desugared away. For example, `for` loops are converted into a `loop` and do not appear in diff --git a/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md new file mode 100644 index 00000000000..b5458d71bf8 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md @@ -0,0 +1 @@ +# Ambig/Unambig Types and Consts \ No newline at end of file diff --git a/src/doc/rustc-dev-guide/src/hir/debugging.md b/src/doc/rustc-dev-guide/src/hir/debugging.md new file mode 100644 index 00000000000..5a0bda20842 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/hir/debugging.md @@ -0,0 +1,15 @@ +# HIR Debugging + +Use the `-Z unpretty=hir` flag to produce a human-readable representation of the HIR. +For cargo projects this can be done with `cargo rustc -- -Z unpretty=hir`. +This output is useful when you need to see at a glance how your code was desugared and transformed +during AST lowering. + +For a full `Debug` dump of the data in the HIR, use the `-Z unpretty=hir-tree` flag. +This may be useful when you need to see the full structure of the HIR from the perspective of the +compiler. + +If you are trying to correlate `NodeId`s or `DefId`s with source code, the +`-Z unpretty=expanded,identified` flag may be useful. + +TODO: anything else? [#1159](https://github.com/rust-lang/rustc-dev-guide/issues/1159) diff --git a/src/doc/rustc-dev-guide/src/hir/lowering.md b/src/doc/rustc-dev-guide/src/hir/lowering.md new file mode 100644 index 00000000000..02c69b8609f --- /dev/null +++ b/src/doc/rustc-dev-guide/src/hir/lowering.md @@ -0,0 +1,48 @@ +# AST lowering + +The AST lowering step converts AST to [HIR](../hir.md). +This means many structures are removed if they are irrelevant +for type analysis or similar syntax agnostic analyses. Examples +of such structures include but are not limited to + +* Parenthesis + * Removed without replacement, the tree structure makes order explicit +* `for` loops and `while (let)` loops + * Converted to `loop` + `match` and some `let` bindings +* `if let` + * Converted to `match` +* Universal `impl Trait` + * Converted to generic arguments + (but with some flags, to know that the user didn't write them) +* Existential `impl Trait` + * Converted to a virtual `existential type` declaration + +Lowering needs to uphold several invariants in order to not trigger the +sanity checks in `compiler/rustc_passes/src/hir_id_validator.rs`: + +1. A `HirId` must be used if created. So if you use the `lower_node_id`, + you *must* use the resulting `NodeId` or `HirId` (either is fine, since + any `NodeId`s in the `HIR` are checked for existing `HirId`s) +2. Lowering a `HirId` must be done in the scope of the *owning* item. + This means you need to use `with_hir_id_owner` if you are creating parts + of an item other than the one being currently lowered. This happens for + example during the lowering of existential `impl Trait` +3. A `NodeId` that will be placed into a HIR structure must be lowered, + even if its `HirId` is unused. Calling + `let _ = self.lower_node_id(node_id);` is perfectly legitimate. +4. If you are creating new nodes that didn't exist in the `AST`, you *must* + create new ids for them. This is done by calling the `next_id` method, + which produces both a new `NodeId` as well as automatically lowering it + for you so you also get the `HirId`. + +If you are creating new `DefId`s, since each `DefId` needs to have a +corresponding `NodeId`, it is advisable to add these `NodeId`s to the +`AST` so you don't have to generate new ones during lowering. This has +the advantage of creating a way to find the `DefId` of something via its +`NodeId`. If lowering needs this `DefId` in multiple places, you can't +generate a new `NodeId` in all those places because you'd also get a new +`DefId` then. With a `NodeId` from the `AST` this is not an issue. + +Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s +instead of lowering having to do it on the fly. Centralizing the `DefId` +generation in one place makes it easier to refactor and reason about. diff --git a/src/doc/rustc-dev-guide/src/overview.md b/src/doc/rustc-dev-guide/src/overview.md index 92d0c7b0c38..8a1a22fad66 100644 --- a/src/doc/rustc-dev-guide/src/overview.md +++ b/src/doc/rustc-dev-guide/src/overview.md @@ -410,7 +410,7 @@ For more details on bootstrapping, see - Guide: [The HIR](hir.md) - Guide: [Identifiers in the HIR](hir.md#identifiers-in-the-hir) - Guide: [The `HIR` Map](hir.md#the-hir-map) - - Guide: [Lowering `AST` to `HIR`](ast-lowering.md) + - Guide: [Lowering `AST` to `HIR`](./hir/lowering.md) - How to view `HIR` representation for your code `cargo rustc -- -Z unpretty=hir-tree` - Rustc `HIR` definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) - Main entry point: **TODO** -- cgit 1.4.1-3-g733a5 From 42888bb0182612046f83ea4e7a284ac43d5b6128 Mon Sep 17 00:00:00 2001 From: Boxy Date: Tue, 17 Jun 2025 15:41:07 +0100 Subject: Write chapter on Unambig vs Ambig Types/Consts --- .../src/hir/ambig-unambig-ty-and-consts.md | 54 +++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md index b5458d71bf8..4d9a2d08137 100644 --- a/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md +++ b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md @@ -1 +1,53 @@ -# Ambig/Unambig Types and Consts \ No newline at end of file +# Ambig/Unambig Types and Consts + +Types and Consts args in the HIR can be in two kinds of positions "ambig" or "unambig". Ambig positions are where +it would be valid to parse either a type or a const, unambig positions are where only one kind would be valid to +parse. + +```rust +fn func(arg: T) { + // ^ Unambig type position + let a: _ = arg; + // ^ Unambig type position + + func::(arg); + // ^ ^ + // ^^^^ Ambig position + + let _: [u8; 10]; + // ^^ ^^ Unambig const position + // ^^ Unambig type position +} + +``` + +Most types/consts in ambig positions are able to be disambiguated as either a type or const during either parsing or ast-lowering. +Currently the only exception to this is inferred generic arguments in path segments. In `Foo<_>` it is not clear whether the `_` argument is an +inferred type argument, or an inferred const argument. + +In unambig positions, inferred arguments are represented with `hir::TyKind::Infer` or `hir::ConstArgKind::Infer` depending on whether it is a type or const position respectively. +In ambig positions, inferred arguments are represented with `hir::GenericArg::Infer`. + +A naive implementation of this structure would result in there being potentially 5 places where an inferred type/const could be found in the HIR if you just looked at the types: +- In unambig type position as a `hir::TyKind::Infer` +- In unambig const arg position as a `hir::ConstArgKind::Infer` +- In an ambig position as a `GenericArg::Ty(TyKind::Infer)` +- In an ambig position as a `GenericArg::Const(ConstArgKind::Infer)` +- In an ambig position as a `GenericArg::Infer` + +This has a few failure modes: +- People may write visitors which check for `GenericArg::Infer` but forget to check for `hir::TyKind/ConstArgKind::Infer`, only handling infers in ambig positions by accident. +- People may write visitors which check for `hir::TyKind/ConstArgKind::Infer` but forget to check for `GenericArg::Infer`, only handling infers in unambig positions by accident. +- People may write visitors which check for `GenerArg::Ty/Const(TyKind/ConstArgKind::Infer)` and `GenerigArg::Infer`, not realising that we never represent inferred types/consts in ambig positions as a `GenericArg::Ty/Const`. +- People may write visitors which check for *only* `TyKind::Infer` and not `ConstArgKind::Infer` forgetting that there are also inferred const arguments (and vice versa). + +To make writing HIR visitors less error prone when caring about inferred types/consts we have a relatively complex system: + +1. We have different types in the compiler for when a type or const is in an unambig or ambig position, `hir::Ty` and `hir::Ty<()>`. `AmbigArg` is an uninhabited type which we use in the `Infer` variant of `TyKind` and `ConstArgKind` to selectively "disable" it if we are in an ambig position. + +2. The `visit_ty` and `visit_const_arg` methods on HIR visitors only accept the ambig position versions of types/consts. Unambig types/consts are implicitly converted to ambig types/consts during the visiting process, with the `Infer` variant handled by a dedicated `visit_infer` method. + +This has a number of benefits: +- It's clear that `GenericArg::Ty/Const` cannot represent inferred type/const arguments +- Implementors of `visit_ty` and `visit_const_arg` will never encounter inferred types/consts making it impossible to write a visitor that seems to work right but handles edge cases wrong +- The `visit_infer` method handles *all* cases of inferred type/consts in the HIR making it easy for visitors to handle inferred type/consts in one dedicated place and not forget cases \ No newline at end of file -- cgit 1.4.1-3-g733a5 From c1506c0cc0bda4f1a2364f4d13993864101b14e4 Mon Sep 17 00:00:00 2001 From: Boxy Date: Tue, 17 Jun 2025 15:48:15 +0100 Subject: Add links --- .../src/hir/ambig-unambig-ty-and-consts.md | 28 +++++++++++++++------- 1 file changed, 19 insertions(+), 9 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md index 4d9a2d08137..a43ad8b4945 100644 --- a/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md +++ b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md @@ -25,29 +25,39 @@ Most types/consts in ambig positions are able to be disambiguated as either a ty Currently the only exception to this is inferred generic arguments in path segments. In `Foo<_>` it is not clear whether the `_` argument is an inferred type argument, or an inferred const argument. -In unambig positions, inferred arguments are represented with `hir::TyKind::Infer` or `hir::ConstArgKind::Infer` depending on whether it is a type or const position respectively. +In unambig positions, inferred arguments are represented with [`hir::TyKind::Infer`][ty_infer] or [`hir::ConstArgKind::Infer`][const_infer] depending on whether it is a type or const position respectively. In ambig positions, inferred arguments are represented with `hir::GenericArg::Infer`. A naive implementation of this structure would result in there being potentially 5 places where an inferred type/const could be found in the HIR if you just looked at the types: - In unambig type position as a `hir::TyKind::Infer` - In unambig const arg position as a `hir::ConstArgKind::Infer` -- In an ambig position as a `GenericArg::Ty(TyKind::Infer)` -- In an ambig position as a `GenericArg::Const(ConstArgKind::Infer)` -- In an ambig position as a `GenericArg::Infer` +- In an ambig position as a [`GenericArg::Type(TyKind::Infer)`][generic_arg_ty] +- In an ambig position as a [`GenericArg::Const(ConstArgKind::Infer)`][generic_arg_const] +- In an ambig position as a [`GenericArg::Infer`][generic_arg_infer] This has a few failure modes: - People may write visitors which check for `GenericArg::Infer` but forget to check for `hir::TyKind/ConstArgKind::Infer`, only handling infers in ambig positions by accident. - People may write visitors which check for `hir::TyKind/ConstArgKind::Infer` but forget to check for `GenericArg::Infer`, only handling infers in unambig positions by accident. -- People may write visitors which check for `GenerArg::Ty/Const(TyKind/ConstArgKind::Infer)` and `GenerigArg::Infer`, not realising that we never represent inferred types/consts in ambig positions as a `GenericArg::Ty/Const`. +- People may write visitors which check for `GenerArg::Type/Const(TyKind/ConstArgKind::Infer)` and `GenerigArg::Infer`, not realising that we never represent inferred types/consts in ambig positions as a `GenericArg::Type/Const`. - People may write visitors which check for *only* `TyKind::Infer` and not `ConstArgKind::Infer` forgetting that there are also inferred const arguments (and vice versa). To make writing HIR visitors less error prone when caring about inferred types/consts we have a relatively complex system: -1. We have different types in the compiler for when a type or const is in an unambig or ambig position, `hir::Ty` and `hir::Ty<()>`. `AmbigArg` is an uninhabited type which we use in the `Infer` variant of `TyKind` and `ConstArgKind` to selectively "disable" it if we are in an ambig position. +1. We have different types in the compiler for when a type or const is in an unambig or ambig position, `hir::Ty` and `hir::Ty<()>`. [`AmbigArg`][ambig_arg] is an uninhabited type which we use in the `Infer` variant of `TyKind` and `ConstArgKind` to selectively "disable" it if we are in an ambig position. -2. The `visit_ty` and `visit_const_arg` methods on HIR visitors only accept the ambig position versions of types/consts. Unambig types/consts are implicitly converted to ambig types/consts during the visiting process, with the `Infer` variant handled by a dedicated `visit_infer` method. +2. The [`visit_ty`][visit_infer] and [`visit_const_arg`][visit_const_arg] methods on HIR visitors only accept the ambig position versions of types/consts. Unambig types/consts are implicitly converted to ambig types/consts during the visiting process, with the `Infer` variant handled by a dedicated [`visit_infer`][visit_infer] method. This has a number of benefits: -- It's clear that `GenericArg::Ty/Const` cannot represent inferred type/const arguments +- It's clear that `GenericArg::Type/Const` cannot represent inferred type/const arguments - Implementors of `visit_ty` and `visit_const_arg` will never encounter inferred types/consts making it impossible to write a visitor that seems to work right but handles edge cases wrong -- The `visit_infer` method handles *all* cases of inferred type/consts in the HIR making it easy for visitors to handle inferred type/consts in one dedicated place and not forget cases \ No newline at end of file +- The `visit_infer` method handles *all* cases of inferred type/consts in the HIR making it easy for visitors to handle inferred type/consts in one dedicated place and not forget cases + +[ty_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.TyKind.html#variant.Infer +[const_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.ConstArgKind.html#variant.Infer +[generic_arg_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Type +[generic_arg_const]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Const +[generic_arg_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Infer +[ambig_arg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.AmbigArg.html +[visit_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/intravisit/trait.Visitor.html#method.visit_ty +[visit_const_arg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/intravisit/trait.Visitor.html#method.visit_const_arg +[visit_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/intravisit/trait.Visitor.html#method.visit_infer \ No newline at end of file -- cgit 1.4.1-3-g733a5 From 39e98006ac3ef94bdb05da9a25d48f8f788c7cd3 Mon Sep 17 00:00:00 2001 From: Boxy Date: Wed, 18 Jun 2025 15:26:18 +0100 Subject: Reviews --- .../src/hir/ambig-unambig-ty-and-consts.md | 24 +++++++++++----------- 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md index a43ad8b4945..709027883ae 100644 --- a/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md +++ b/src/doc/rustc-dev-guide/src/hir/ambig-unambig-ty-and-consts.md @@ -1,11 +1,11 @@ # Ambig/Unambig Types and Consts -Types and Consts args in the HIR can be in two kinds of positions "ambig" or "unambig". Ambig positions are where +Types and Consts args in the HIR can be in two kinds of positions ambiguous (ambig) or unambiguous (unambig). Ambig positions are where it would be valid to parse either a type or a const, unambig positions are where only one kind would be valid to parse. ```rust -fn func(arg: T) { +fn func(arg: T) { // ^ Unambig type position let a: _ = arg; // ^ Unambig type position @@ -21,19 +21,19 @@ fn func(arg: T) { ``` -Most types/consts in ambig positions are able to be disambiguated as either a type or const during either parsing or ast-lowering. -Currently the only exception to this is inferred generic arguments in path segments. In `Foo<_>` it is not clear whether the `_` argument is an -inferred type argument, or an inferred const argument. +Most types/consts in ambig positions are able to be disambiguated as either a type or const during parsing. Single segment paths are always represented as types in the AST but may get resolved to a const parameter during name resolution, then lowered to a const argument during ast-lowering. The only generic arguments which remain ambiguous after lowering are inferred generic arguments (`_`) in path segments. For example, in `Foo<_>` it is not clear whether the `_` argument is an inferred type argument, or an inferred const argument. In unambig positions, inferred arguments are represented with [`hir::TyKind::Infer`][ty_infer] or [`hir::ConstArgKind::Infer`][const_infer] depending on whether it is a type or const position respectively. In ambig positions, inferred arguments are represented with `hir::GenericArg::Infer`. -A naive implementation of this structure would result in there being potentially 5 places where an inferred type/const could be found in the HIR if you just looked at the types: -- In unambig type position as a `hir::TyKind::Infer` -- In unambig const arg position as a `hir::ConstArgKind::Infer` -- In an ambig position as a [`GenericArg::Type(TyKind::Infer)`][generic_arg_ty] -- In an ambig position as a [`GenericArg::Const(ConstArgKind::Infer)`][generic_arg_const] -- In an ambig position as a [`GenericArg::Infer`][generic_arg_infer] +A naive implementation of this would result in there being potentially 5 places where you might think an inferred type/const could be found in the HIR from looking at the structure of the HIR: +1. In unambig type position as a `hir::TyKind::Infer` +2. In unambig const arg position as a `hir::ConstArgKind::Infer` +3. In an ambig position as a [`GenericArg::Type(TyKind::Infer)`][generic_arg_ty] +4. In an ambig position as a [`GenericArg::Const(ConstArgKind::Infer)`][generic_arg_const] +5. In an ambig position as a [`GenericArg::Infer`][generic_arg_infer] + +Note that places 3 and 4 would never actually be possible to encounter as we always lower to `GenericArg::Infer` in generic arg position. This has a few failure modes: - People may write visitors which check for `GenericArg::Infer` but forget to check for `hir::TyKind/ConstArgKind::Infer`, only handling infers in ambig positions by accident. @@ -45,7 +45,7 @@ To make writing HIR visitors less error prone when caring about inferred types/c 1. We have different types in the compiler for when a type or const is in an unambig or ambig position, `hir::Ty` and `hir::Ty<()>`. [`AmbigArg`][ambig_arg] is an uninhabited type which we use in the `Infer` variant of `TyKind` and `ConstArgKind` to selectively "disable" it if we are in an ambig position. -2. The [`visit_ty`][visit_infer] and [`visit_const_arg`][visit_const_arg] methods on HIR visitors only accept the ambig position versions of types/consts. Unambig types/consts are implicitly converted to ambig types/consts during the visiting process, with the `Infer` variant handled by a dedicated [`visit_infer`][visit_infer] method. +2. The [`visit_ty`][visit_ty] and [`visit_const_arg`][visit_const_arg] methods on HIR visitors only accept the ambig position versions of types/consts. Unambig types/consts are implicitly converted to ambig types/consts during the visiting process, with the `Infer` variant handled by a dedicated [`visit_infer`][visit_infer] method. This has a number of benefits: - It's clear that `GenericArg::Type/Const` cannot represent inferred type/const arguments -- cgit 1.4.1-3-g733a5 From 4145596954c7ea313a9f9403044e05d57d175235 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Thu, 19 Jun 2025 00:03:33 +0200 Subject: fix markup That was intended to be a list. Also, the order is not relevant. --- src/doc/rustc-dev-guide/src/building/new-target.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/building/new-target.md b/src/doc/rustc-dev-guide/src/building/new-target.md index 8d323ba9646..e11a2cd8ee5 100644 --- a/src/doc/rustc-dev-guide/src/building/new-target.md +++ b/src/doc/rustc-dev-guide/src/building/new-target.md @@ -174,8 +174,8 @@ compiler, you can use it instead of the JSON file for both arguments. ## Promoting a target from tier 2 (target) to tier 2 (host) There are two levels of tier 2 targets: - a) Targets that are only cross-compiled (`rustup target add`) - b) Targets that [have a native toolchain][tier2-native] (`rustup toolchain install`) +- Targets that are only cross-compiled (`rustup target add`) +- Targets that [have a native toolchain][tier2-native] (`rustup toolchain install`) [tier2-native]: https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-2-with-host-tools -- cgit 1.4.1-3-g733a5 From 0a185e422ccac38f0fb856b81c5f955873ff7cd0 Mon Sep 17 00:00:00 2001 From: Manuel Drehwald Date: Mon, 2 Jun 2025 12:06:27 -0700 Subject: initial instructions for gpu offload --- src/doc/rustc-dev-guide/src/SUMMARY.md | 2 + .../rustc-dev-guide/src/offload/installation.md | 71 ++++++++++++++++++++++ src/doc/rustc-dev-guide/src/offload/internals.md | 9 +++ 3 files changed, 82 insertions(+) create mode 100644 src/doc/rustc-dev-guide/src/offload/installation.md create mode 100644 src/doc/rustc-dev-guide/src/offload/internals.md (limited to 'src') diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index 50a3f44add3..7f2f32c62ff 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/src/SUMMARY.md @@ -101,6 +101,8 @@ - [The `rustdoc` test suite](./rustdoc-internals/rustdoc-test-suite.md) - [The `rustdoc-gui` test suite](./rustdoc-internals/rustdoc-gui-test-suite.md) - [The `rustdoc-json` test suite](./rustdoc-internals/rustdoc-json-test-suite.md) +- [GPU offload internals](./offload/internals.md) + - [Installation](./offload/installation.md) - [Autodiff internals](./autodiff/internals.md) - [Installation](./autodiff/installation.md) - [How to debug](./autodiff/debugging.md) diff --git a/src/doc/rustc-dev-guide/src/offload/installation.md b/src/doc/rustc-dev-guide/src/offload/installation.md new file mode 100644 index 00000000000..2536af09a23 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/offload/installation.md @@ -0,0 +1,71 @@ +# Installation + +In the future, `std::offload` should become available in nightly builds for users. For now, everyone still needs to build rustc from source. + +## Build instructions + +First you need to clone and configure the Rust repository: +```bash +git clone --depth=1 git@github.com:rust-lang/rust.git +cd rust +./configure --enable-llvm-link-shared --release-channel=nightly --enable-llvm-assertions --enable-offload --enable-enzyme --enable-clang --enable-lld --enable-option-checking --enable-ninja --disable-docs +``` + +Afterwards you can build rustc using: +```bash +./x.py build --stage 1 library +``` + +Afterwards rustc toolchain link will allow you to use it through cargo: +``` +rustup toolchain link offload build/host/stage1 +rustup toolchain install nightly # enables -Z unstable-options +``` + + + +## Build instruction for LLVM itself +```bash +git clone --depth=1 git@github.com:llvm/llvm-project.git +cd llvm-project +mkdir build +cd build +cmake -G Ninja ../llvm -DLLVM_TARGETS_TO_BUILD="host,AMDGPU,NVPTX" -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_ENABLE_RUNTIMES="offload,openmp" -DLLVM_ENABLE_PLUGINS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=. +ninja +ninja install +``` +This gives you a working LLVM build. + + +## Testing +run +``` +./x.py test --stage 1 tests/codegen/gpu_offload +``` + +## Usage +It is important to use a clang compiler build on the same llvm as rustc. Just calling clang without the full path will likely use your system clang, which probably will be incompatible. +``` +/absolute/path/to/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc --edition=2024 --crate-type cdylib src/main.rs --emit=llvm-ir -O -C lto=fat -Cpanic=abort -Zoffload=Enable +/absolute/path/to/rust/build/x86_64-unknown-linux-gnu/llvm/bin/clang++ -fopenmp --offload-arch=native -g -O3 main.ll -o main -save-temps +LIBOMPTARGET_INFO=-1 ./main +``` +The first step will generate a `main.ll` file, which has enough instructions to cause the offload runtime to move data to and from a gpu. +The second step will use clang as the compilation driver to compile our IR file down to a working binary. Only a very small Rust subset will work out of the box here, unless +you use features like build-std, which are not covered by this guide. Look at the codegen test to get a feeling for how to write a working example. +In the last step you can run your binary, if all went well you will see a data transfer being reported: +``` +omptarget device 0 info: Entering OpenMP data region with being_mapper at unknown:0:0 with 1 arguments: +omptarget device 0 info: tofrom(unknown)[1024] +omptarget device 0 info: Creating new map entry with HstPtrBase=0x00007fffffff9540, HstPtrBegin=0x00007fffffff9540, TgtAllocBegin=0x0000155547200000, TgtPtrBegin=0x0000155547200000, Size=1024, DynRefCount=1, HoldRefCount=0, Name=unknown +omptarget device 0 info: Copying data from host to device, HstPtr=0x00007fffffff9540, TgtPtr=0x0000155547200000, Size=1024, Name=unknown +omptarget device 0 info: OpenMP Host-Device pointer mappings after block at unknown:0:0: +omptarget device 0 info: Host Ptr Target Ptr Size (B) DynRefCount HoldRefCount Declaration +omptarget device 0 info: 0x00007fffffff9540 0x0000155547200000 1024 1 0 unknown at unknown:0:0 +// some other output +omptarget device 0 info: Exiting OpenMP data region with end_mapper at unknown:0:0 with 1 arguments: +omptarget device 0 info: tofrom(unknown)[1024] +omptarget device 0 info: Mapping exists with HstPtrBegin=0x00007fffffff9540, TgtPtrBegin=0x0000155547200000, Size=1024, DynRefCount=0 (decremented, delayed deletion), HoldRefCount=0 +omptarget device 0 info: Copying data from device to host, TgtPtr=0x0000155547200000, HstPtr=0x00007fffffff9540, Size=1024, Name=unknown +omptarget device 0 info: Removing map entry with HstPtrBegin=0x00007fffffff9540, TgtPtrBegin=0x0000155547200000, Size=1024, Name=unknown +``` diff --git a/src/doc/rustc-dev-guide/src/offload/internals.md b/src/doc/rustc-dev-guide/src/offload/internals.md new file mode 100644 index 00000000000..28857a6e78b --- /dev/null +++ b/src/doc/rustc-dev-guide/src/offload/internals.md @@ -0,0 +1,9 @@ +# std::offload + +This module is under active development. Once upstream, it should allow Rust developers to run Rust code on GPUs. +We aim to develop a `rusty` GPU programming interface, which is safe, convenient and sufficiently fast by default. +This includes automatic data movement to and from the GPU, in a efficient way. We will (later) +also offer more advanced, possibly unsafe, interfaces which allow a higher degree of control. + +The implementation is based on LLVM's "offload" project, which is already used by OpenMP to run Fortran or C++ code on GPUs. +While the project is under development, users will need to call other compilers like clang to finish the compilation process. -- cgit 1.4.1-3-g733a5 From 48b36ee8ad3a2dc61e5ed1248621b4371bd1f147 Mon Sep 17 00:00:00 2001 From: The rustc-dev-guide Cronjob Bot Date: Thu, 19 Jun 2025 04:07:21 +0000 Subject: Preparing for merge from rustc --- src/doc/rustc-dev-guide/rust-version | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src') diff --git a/src/doc/rustc-dev-guide/rust-version b/src/doc/rustc-dev-guide/rust-version index 86d35b31498..30ba3070e1f 100644 --- a/src/doc/rustc-dev-guide/rust-version +++ b/src/doc/rustc-dev-guide/rust-version @@ -1 +1 @@ -14346303d760027e53214e705109a62c0f00b214 +d1d8e386c5e84c4ba857f56c3291f73c27e2d62a -- cgit 1.4.1-3-g733a5 From 8c281613739436582f979d228be4cc1d4f7afa3d Mon Sep 17 00:00:00 2001 From: Jakub Beránek Date: Tue, 17 Jun 2025 16:09:30 +0200 Subject: Add `get_host_target` function --- src/bootstrap/src/core/config/config.rs | 4 ++-- src/bootstrap/src/utils/helpers.rs | 5 +++++ 2 files changed, 7 insertions(+), 2 deletions(-) (limited to 'src') diff --git a/src/bootstrap/src/core/config/config.rs b/src/bootstrap/src/core/config/config.rs index ff0fda2d2e6..d3393afcae0 100644 --- a/src/bootstrap/src/core/config/config.rs +++ b/src/bootstrap/src/core/config/config.rs @@ -49,7 +49,7 @@ use crate::core::download::is_download_ci_available; use crate::utils::channel; use crate::utils::exec::command; use crate::utils::execution_context::ExecutionContext; -use crate::utils::helpers::exe; +use crate::utils::helpers::{exe, get_host_target}; use crate::{GitInfo, OnceLock, TargetSelection, check_ci_llvm, helpers, t}; /// Each path in this list is considered "allowed" in the `download-rustc="if-unchanged"` logic. @@ -349,7 +349,7 @@ impl Config { stderr_is_tty: std::io::stderr().is_terminal(), // set by build.rs - host_target: TargetSelection::from_user(env!("BUILD_TRIPLE")), + host_target: get_host_target(), src: { let manifest_dir = PathBuf::from(env!("CARGO_MANIFEST_DIR")); diff --git a/src/bootstrap/src/utils/helpers.rs b/src/bootstrap/src/utils/helpers.rs index 2f18fb60318..3c5f612daa7 100644 --- a/src/bootstrap/src/utils/helpers.rs +++ b/src/bootstrap/src/utils/helpers.rs @@ -178,6 +178,11 @@ pub fn symlink_dir(config: &Config, original: &Path, link: &Path) -> io::Result< } } +/// Return the host target on which we are currently running. +pub fn get_host_target() -> TargetSelection { + TargetSelection::from_user(env!("BUILD_TRIPLE")) +} + /// Rename a file if from and to are in the same filesystem or /// copy and remove the file otherwise pub fn move_file, Q: AsRef>(from: P, to: Q) -> io::Result<()> { -- cgit 1.4.1-3-g733a5 From 21d21d5f81d6d0ac7e58275e40e982550951ec86 Mon Sep 17 00:00:00 2001 From: Jakub Beránek Date: Tue, 17 Jun 2025 16:16:46 +0200 Subject: Normalize host target in snapshot tests --- src/bootstrap/src/core/builder/tests.rs | 48 +++++++++++++++++++++------------ src/bootstrap/src/utils/tests/mod.rs | 43 +++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+), 17 deletions(-) (limited to 'src') diff --git a/src/bootstrap/src/core/builder/tests.rs b/src/bootstrap/src/core/builder/tests.rs index 6268a2b59d6..f45afe0c789 100644 --- a/src/bootstrap/src/core/builder/tests.rs +++ b/src/bootstrap/src/core/builder/tests.rs @@ -9,6 +9,7 @@ use crate::Flags; use crate::core::build_steps::doc::DocumentationFormat; use crate::core::config::Config; use crate::utils::cache::ExecutedStep; +use crate::utils::helpers::get_host_target; use crate::utils::tests::git::{GitCtx, git_test}; static TEST_TRIPLE_1: &str = "i686-unknown-haiku"; @@ -1236,24 +1237,38 @@ fn any_debug() { /// The staging tests use insta for snapshot testing. /// See bootstrap's README on how to bless the snapshots. mod staging { + use crate::Build; + use crate::core::builder::Builder; use crate::core::builder::tests::{ TEST_TRIPLE_1, configure, configure_with_args, render_steps, run_build, }; + use crate::utils::tests::ConfigBuilder; #[test] fn build_compiler_stage_1() { - let mut cache = run_build( - &["compiler".into()], - configure_with_args(&["build", "--stage", "1"], &[TEST_TRIPLE_1], &[TEST_TRIPLE_1]), - ); - let steps = cache.into_executed_steps(); - insta::assert_snapshot!(render_steps(&steps), @r" - [build] rustc 0 -> std 0 - [build] llvm - [build] rustc 0 -> rustc 1 - [build] rustc 0 -> rustc 1 + insta::assert_snapshot!( + ConfigBuilder::build() + .path("compiler") + .stage(1) + .get_steps(), @r" + [build] rustc 0 -> std 0 + [build] llvm + [build] rustc 0 -> rustc 1 + [build] rustc 0 -> rustc 1 "); } + + impl ConfigBuilder { + fn get_steps(self) -> String { + let config = self.create_config(); + + let kind = config.cmd.kind(); + let build = Build::new(config); + let builder = Builder::new(&build); + builder.run_step_descriptions(&Builder::get_step_descriptions(kind), &builder.paths); + render_steps(&builder.cache.into_executed_steps()) + } + } } /// Renders the executed bootstrap steps for usage in snapshot tests with insta. @@ -1275,18 +1290,17 @@ fn render_steps(steps: &[ExecutedStep]) -> String { } let stage = if let Some(stage) = metadata.stage { format!("{stage} ") } else { "".to_string() }; - write!(record, "{} {stage}<{}>", metadata.name, metadata.target); + write!(record, "{} {stage}<{}>", metadata.name, normalize_target(metadata.target)); Some(record) }) - .map(|line| { - line.replace(TEST_TRIPLE_1, "target1") - .replace(TEST_TRIPLE_2, "target2") - .replace(TEST_TRIPLE_3, "target3") - }) .collect::>() .join("\n") } +fn normalize_target(target: TargetSelection) -> String { + target.to_string().replace(&get_host_target().to_string(), "host") +} + fn render_compiler(compiler: Compiler) -> String { - format!("rustc {} <{}>", compiler.stage, compiler.host) + format!("rustc {} <{}>", compiler.stage, normalize_target(compiler.host)) } diff --git a/src/bootstrap/src/utils/tests/mod.rs b/src/bootstrap/src/utils/tests/mod.rs index 73c500f6e36..ec6293f3c2c 100644 --- a/src/bootstrap/src/utils/tests/mod.rs +++ b/src/bootstrap/src/utils/tests/mod.rs @@ -1,3 +1,46 @@ //! This module contains shared utilities for bootstrap tests. +use crate::core::builder::Builder; +use crate::core::config::DryRun; +use crate::{Build, Config, Flags}; + pub mod git; + +/// Used to configure an invocation of bootstrap. +/// Currently runs in the rustc checkout, long-term it should be switched +/// to run in a (cache-primed) temporary directory instead. +pub struct ConfigBuilder { + args: Vec, +} + +impl ConfigBuilder { + pub fn from_args(args: &[&str]) -> Self { + Self::new(args) + } + + pub fn build() -> Self { + Self::new(&["build"]) + } + + pub fn path(mut self, path: &str) -> Self { + self.args.push(path.to_string()); + self + } + + pub fn stage(mut self, stage: u32) -> Self { + self.args.push("--stage".to_string()); + self.args.push(stage.to_string()); + self + } + + fn new(args: &[&str]) -> Self { + Self { args: args.iter().copied().map(String::from).collect() } + } + + pub fn create_config(mut self) -> Config { + let mut config = Config::parse(Flags::parse(&self.args)); + // Run in dry-check, otherwise the test would be too slow + config.set_dry_run(DryRun::SelfCheck); + config + } +} -- cgit 1.4.1-3-g733a5 From 718e475cb12094cb182a8271b1855d8f1663dc3a Mon Sep 17 00:00:00 2001 From: Jakub Beránek Date: Wed, 18 Jun 2025 13:14:16 +0200 Subject: Clarify arrow in snapshot tests --- src/bootstrap/src/core/builder/tests.rs | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'src') diff --git a/src/bootstrap/src/core/builder/tests.rs b/src/bootstrap/src/core/builder/tests.rs index f45afe0c789..1d1c315c1cf 100644 --- a/src/bootstrap/src/core/builder/tests.rs +++ b/src/bootstrap/src/core/builder/tests.rs @@ -1274,6 +1274,10 @@ mod staging { /// Renders the executed bootstrap steps for usage in snapshot tests with insta. /// Only renders certain important steps. /// Each value in `steps` should be a tuple of (Step, step output). +/// +/// The arrow in the rendered output (`X -> Y`) means `X builds Y`. +/// This is similar to the output printed by bootstrap to stdout, but here it is +/// generated purely for the purpose of tests. fn render_steps(steps: &[ExecutedStep]) -> String { steps .iter() -- cgit 1.4.1-3-g733a5 From eefd59872565330fc5905dc5903a56ce93fca47e Mon Sep 17 00:00:00 2001 From: Folkert de Vries Date: Thu, 19 Jun 2025 12:40:50 +0200 Subject: correct template for `#[align]` it should not suggest just `#[align]` --- compiler/rustc_attr_parsing/src/attributes/repr.rs | 2 +- compiler/rustc_feature/src/unstable.rs | 2 +- .../src/compiler-flags/min-function-alignment.md | 2 +- tests/ui/attributes/malformed-fn-align.rs | 5 ++- tests/ui/attributes/malformed-fn-align.stderr | 49 +++++++++++----------- .../ui/feature-gates/feature-gate-fn_align.stderr | 10 ++--- 6 files changed, 36 insertions(+), 34 deletions(-) (limited to 'src') diff --git a/compiler/rustc_attr_parsing/src/attributes/repr.rs b/compiler/rustc_attr_parsing/src/attributes/repr.rs index c9f9f34bdb7..eb16c3f95f0 100644 --- a/compiler/rustc_attr_parsing/src/attributes/repr.rs +++ b/compiler/rustc_attr_parsing/src/attributes/repr.rs @@ -273,7 +273,7 @@ pub(crate) struct AlignParser(Option<(Align, Span)>); impl AlignParser { const PATH: &'static [Symbol] = &[sym::align]; - const TEMPLATE: AttributeTemplate = template!(Word, List: ""); + const TEMPLATE: AttributeTemplate = template!(List: ""); fn parse<'c, S: Stage>( &mut self, diff --git a/compiler/rustc_feature/src/unstable.rs b/compiler/rustc_feature/src/unstable.rs index a7bc6207149..91715851226 100644 --- a/compiler/rustc_feature/src/unstable.rs +++ b/compiler/rustc_feature/src/unstable.rs @@ -510,7 +510,7 @@ declare_features! ( (unstable, ffi_pure, "1.45.0", Some(58329)), /// Controlling the behavior of fmt::Debug (unstable, fmt_debug, "1.82.0", Some(129709)), - /// Allows using `#[repr(align(...))]` on function items + /// Allows using `#[align(...)]` on function items (unstable, fn_align, "1.53.0", Some(82232)), /// Support delegating implementation of functions to other already implemented functions. (incomplete, fn_delegation, "1.76.0", Some(118212)), diff --git a/src/doc/unstable-book/src/compiler-flags/min-function-alignment.md b/src/doc/unstable-book/src/compiler-flags/min-function-alignment.md index b7a3aa71fc4..03e576e3e30 100644 --- a/src/doc/unstable-book/src/compiler-flags/min-function-alignment.md +++ b/src/doc/unstable-book/src/compiler-flags/min-function-alignment.md @@ -15,7 +15,7 @@ This flag is equivalent to: - `-fmin-function-alignment` for [GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fmin-function-alignment_003dn) - `-falign-functions` for [Clang](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang1-falign-functions) -The specified alignment is a minimum. A higher alignment can be specified for specific functions by using the [`repr(align(...))`](https://github.com/rust-lang/rust/issues/82232) feature and annotating the function with a `#[repr(align())]` attribute. The attribute's value is ignored when it is lower than the value passed to `min-function-alignment`. +The specified alignment is a minimum. A higher alignment can be specified for specific functions by using the [`align(...)`](https://github.com/rust-lang/rust/issues/82232) feature and annotating the function with a `#[align()]` attribute. The attribute's value is ignored when it is lower than the value passed to `min-function-alignment`. There are two additional edge cases for this flag: diff --git a/tests/ui/attributes/malformed-fn-align.rs b/tests/ui/attributes/malformed-fn-align.rs index 35ffd6d8acc..f5ab9555e56 100644 --- a/tests/ui/attributes/malformed-fn-align.rs +++ b/tests/ui/attributes/malformed-fn-align.rs @@ -3,7 +3,10 @@ trait MyTrait { #[align] //~ ERROR malformed `align` attribute input - fn myfun(); + fn myfun1(); + + #[align(1, 2)] //~ ERROR malformed `align` attribute input + fn myfun2(); } #[align = 16] //~ ERROR malformed `align` attribute input diff --git a/tests/ui/attributes/malformed-fn-align.stderr b/tests/ui/attributes/malformed-fn-align.stderr index 765255c2c3a..b769d0b457d 100644 --- a/tests/ui/attributes/malformed-fn-align.stderr +++ b/tests/ui/attributes/malformed-fn-align.stderr @@ -2,54 +2,55 @@ error[E0539]: malformed `align` attribute input --> $DIR/malformed-fn-align.rs:5:5 | LL | #[align] - | ^^^^^^^^ expected this to be a list - | -help: try changing it to one of the following valid forms of the attribute - | -LL | #[align()] - | ++++++++++++++++++++++ + | ^^^^^^^^ + | | + | expected this to be a list + | help: must be of the form: `#[align()]` + +error[E0805]: malformed `align` attribute input + --> $DIR/malformed-fn-align.rs:8:5 + | +LL | #[align(1, 2)] + | ^^^^^^^------^ + | | | + | | expected a single argument here + | help: must be of the form: `#[align()]` error[E0539]: malformed `align` attribute input - --> $DIR/malformed-fn-align.rs:9:1 + --> $DIR/malformed-fn-align.rs:12:1 | LL | #[align = 16] - | ^^^^^^^^^^^^^ expected this to be a list - | -help: try changing it to one of the following valid forms of the attribute - | -LL - #[align = 16] -LL + #[align()] - | -LL - #[align = 16] -LL + #[align] - | + | ^^^^^^^^^^^^^ + | | + | expected this to be a list + | help: must be of the form: `#[align()]` error[E0589]: invalid alignment value: not an unsuffixed integer - --> $DIR/malformed-fn-align.rs:12:9 + --> $DIR/malformed-fn-align.rs:15:9 | LL | #[align("hello")] | ^^^^^^^ error[E0589]: invalid alignment value: not a power of two - --> $DIR/malformed-fn-align.rs:15:9 + --> $DIR/malformed-fn-align.rs:18:9 | LL | #[align(0)] | ^ error: `#[repr(align(...))]` is not supported on function items - --> $DIR/malformed-fn-align.rs:18:8 + --> $DIR/malformed-fn-align.rs:21:8 | LL | #[repr(align(16))] | ^^^^^^^^^ | help: use `#[align(...)]` instead - --> $DIR/malformed-fn-align.rs:18:8 + --> $DIR/malformed-fn-align.rs:21:8 | LL | #[repr(align(16))] | ^^^^^^^^^ error: `#[align(...)]` is not supported on struct items - --> $DIR/malformed-fn-align.rs:21:1 + --> $DIR/malformed-fn-align.rs:24:1 | LL | #[align(16)] | ^^^^^^^^^^^^ @@ -60,7 +61,7 @@ LL - #[align(16)] LL + #[repr(align(16))] | -error: aborting due to 6 previous errors +error: aborting due to 7 previous errors -Some errors have detailed explanations: E0539, E0589. +Some errors have detailed explanations: E0539, E0589, E0805. For more information about an error, try `rustc --explain E0539`. diff --git a/tests/ui/feature-gates/feature-gate-fn_align.stderr b/tests/ui/feature-gates/feature-gate-fn_align.stderr index 93ef136dc73..921cf08435c 100644 --- a/tests/ui/feature-gates/feature-gate-fn_align.stderr +++ b/tests/ui/feature-gates/feature-gate-fn_align.stderr @@ -22,12 +22,10 @@ error[E0539]: malformed `align` attribute input --> $DIR/feature-gate-fn_align.rs:8:5 | LL | #[align] - | ^^^^^^^^ expected this to be a list - | -help: try changing it to one of the following valid forms of the attribute - | -LL | #[align()] - | ++++++++++++++++++++++ + | ^^^^^^^^ + | | + | expected this to be a list + | help: must be of the form: `#[align()]` error: aborting due to 3 previous errors -- cgit 1.4.1-3-g733a5 From aca0688a1dd16e0bc41ac41c5b861384c418427e Mon Sep 17 00:00:00 2001 From: Yotam Ofek Date: Thu, 19 Jun 2025 13:50:54 +0000 Subject: De-dup common code from `ExternalCrate` methods --- src/librustdoc/clean/types.rs | 118 ++++++++++++--------------- src/librustdoc/clean/utils.rs | 4 +- src/librustdoc/passes/collect_trait_impls.rs | 2 +- 3 files changed, 53 insertions(+), 71 deletions(-) (limited to 'src') diff --git a/src/librustdoc/clean/types.rs b/src/librustdoc/clean/types.rs index 2d9670a3d10..408ef611ee5 100644 --- a/src/librustdoc/clean/types.rs +++ b/src/librustdoc/clean/types.rs @@ -4,6 +4,7 @@ use std::sync::{Arc, OnceLock as OnceCell}; use std::{fmt, iter}; use arrayvec::ArrayVec; +use itertools::Either; use rustc_abi::{ExternAbi, VariantIdx}; use rustc_attr_data_structures::{ AttributeKind, ConstStability, Deprecation, Stability, StableSince, @@ -199,49 +200,49 @@ impl ExternalCrate { .unwrap_or(Unknown) // Well, at least we tried. } - pub(crate) fn keywords(&self, tcx: TyCtxt<'_>) -> ThinVec<(DefId, Symbol)> { + fn mapped_root_modules( + &self, + tcx: TyCtxt<'_>, + f: impl Fn(DefId, TyCtxt<'_>) -> Option<(DefId, T)>, + ) -> impl Iterator { let root = self.def_id(); - let as_keyword = |res: Res| { - if let Res::Def(DefKind::Mod, def_id) = res { - let mut keyword = None; - let meta_items = tcx - .get_attrs(def_id, sym::doc) - .flat_map(|attr| attr.meta_item_list().unwrap_or_default()); - for meta in meta_items { - if meta.has_name(sym::keyword) - && let Some(v) = meta.value_str() - { - keyword = Some(v); - break; - } - } - return keyword.map(|p| (def_id, p)); - } - None - }; if root.is_local() { - tcx.hir_root_module() - .item_ids - .iter() - .filter_map(|&id| { - let item = tcx.hir_item(id); - match item.kind { - hir::ItemKind::Mod(..) => { - as_keyword(Res::Def(DefKind::Mod, id.owner_id.to_def_id())) - } - _ => None, - } - }) - .collect() + Either::Left( + tcx.hir_root_module() + .item_ids + .iter() + .filter(move |&&id| matches!(tcx.hir_item(id).kind, hir::ItemKind::Mod(..))) + .filter_map(move |&id| f(id.owner_id.into(), tcx)), + ) } else { - tcx.module_children(root).iter().map(|item| item.res).filter_map(as_keyword).collect() + Either::Right( + tcx.module_children(root) + .iter() + .filter_map(|item| { + if let Res::Def(DefKind::Mod, did) = item.res { Some(did) } else { None } + }) + .filter_map(move |did| f(did, tcx)), + ) } } - pub(crate) fn primitives(&self, tcx: TyCtxt<'_>) -> ThinVec<(DefId, PrimitiveType)> { - let root = self.def_id(); + pub(crate) fn keywords(&self, tcx: TyCtxt<'_>) -> impl Iterator { + fn as_keyword(did: DefId, tcx: TyCtxt<'_>) -> Option<(DefId, Symbol)> { + tcx.get_attrs(did, sym::doc) + .flat_map(|attr| attr.meta_item_list().unwrap_or_default()) + .filter(|meta| meta.has_name(sym::keyword)) + .find_map(|meta| meta.value_str()) + .map(|value| (did, value)) + } + self.mapped_root_modules(tcx, as_keyword) + } + + pub(crate) fn primitives( + &self, + tcx: TyCtxt<'_>, + ) -> impl Iterator { // Collect all inner modules which are tagged as implementations of // primitives. // @@ -259,40 +260,21 @@ impl ExternalCrate { // Also note that this does not attempt to deal with modules tagged // duplicately for the same primitive. This is handled later on when // rendering by delegating everything to a hash map. - let as_primitive = |res: Res| { - let Res::Def(DefKind::Mod, def_id) = res else { return None }; - tcx.get_attrs(def_id, sym::rustc_doc_primitive) - .map(|attr| { - let attr_value = attr.value_str().expect("syntax should already be validated"); - let Some(prim) = PrimitiveType::from_symbol(attr_value) else { - span_bug!( - attr.span(), - "primitive `{attr_value}` is not a member of `PrimitiveType`" - ); - }; - - (def_id, prim) - }) - .next() - }; + fn as_primitive(def_id: DefId, tcx: TyCtxt<'_>) -> Option<(DefId, PrimitiveType)> { + tcx.get_attrs(def_id, sym::rustc_doc_primitive).next().map(|attr| { + let attr_value = attr.value_str().expect("syntax should already be validated"); + let Some(prim) = PrimitiveType::from_symbol(attr_value) else { + span_bug!( + attr.span(), + "primitive `{attr_value}` is not a member of `PrimitiveType`" + ); + }; - if root.is_local() { - tcx.hir_root_module() - .item_ids - .iter() - .filter_map(|&id| { - let item = tcx.hir_item(id); - match item.kind { - hir::ItemKind::Mod(..) => { - as_primitive(Res::Def(DefKind::Mod, id.owner_id.to_def_id())) - } - _ => None, - } - }) - .collect() - } else { - tcx.module_children(root).iter().map(|item| item.res).filter_map(as_primitive).collect() + (def_id, prim) + }) } + + self.mapped_root_modules(tcx, as_primitive) } } @@ -1966,7 +1948,7 @@ impl PrimitiveType { let e = ExternalCrate { crate_num }; let crate_name = e.name(tcx); debug!(?crate_num, ?crate_name); - for &(def_id, prim) in &e.primitives(tcx) { + for (def_id, prim) in e.primitives(tcx) { // HACK: try to link to std instead where possible if crate_name == sym::core && primitive_locations.contains_key(&prim) { continue; diff --git a/src/librustdoc/clean/utils.rs b/src/librustdoc/clean/utils.rs index c58b07a5b67..2c9878636ab 100644 --- a/src/librustdoc/clean/utils.rs +++ b/src/librustdoc/clean/utils.rs @@ -61,7 +61,7 @@ pub(crate) fn krate(cx: &mut DocContext<'_>) -> Crate { let keywords = local_crate.keywords(cx.tcx); { let ItemKind::ModuleItem(m) = &mut module.inner.kind else { unreachable!() }; - m.items.extend(primitives.iter().map(|&(def_id, prim)| { + m.items.extend(primitives.map(|(def_id, prim)| { Item::from_def_id_and_parts( def_id, Some(prim.as_sym()), @@ -69,7 +69,7 @@ pub(crate) fn krate(cx: &mut DocContext<'_>) -> Crate { cx, ) })); - m.items.extend(keywords.into_iter().map(|(def_id, kw)| { + m.items.extend(keywords.map(|(def_id, kw)| { Item::from_def_id_and_parts(def_id, Some(kw), ItemKind::KeywordItem, cx) })); } diff --git a/src/librustdoc/passes/collect_trait_impls.rs b/src/librustdoc/passes/collect_trait_impls.rs index f4e4cd924f7..2339a6b69cd 100644 --- a/src/librustdoc/passes/collect_trait_impls.rs +++ b/src/librustdoc/passes/collect_trait_impls.rs @@ -35,7 +35,7 @@ pub(crate) fn collect_trait_impls(mut krate: Crate, cx: &mut DocContext<'_>) -> }); let local_crate = ExternalCrate { crate_num: LOCAL_CRATE }; - let prims: FxHashSet = local_crate.primitives(tcx).iter().map(|p| p.1).collect(); + let prims: FxHashSet = local_crate.primitives(tcx).map(|(_, p)| p).collect(); let crate_items = { let mut coll = ItemAndAliasCollector::new(&cx.cache); -- cgit 1.4.1-3-g733a5 From fca6e81735c7d31fcfd39aa10126f3e5041dbecb Mon Sep 17 00:00:00 2001 From: Jieyou Xu Date: Fri, 20 Jun 2025 07:44:18 +0800 Subject: Make sure to rebuild rustdoc if `src/rustdoc-json-types` is changed --- src/bootstrap/src/core/build_steps/tool.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src') diff --git a/src/bootstrap/src/core/build_steps/tool.rs b/src/bootstrap/src/core/build_steps/tool.rs index 0088e851d39..41f83da13f4 100644 --- a/src/bootstrap/src/core/build_steps/tool.rs +++ b/src/bootstrap/src/core/build_steps/tool.rs @@ -716,7 +716,7 @@ impl Step for Rustdoc { && target_compiler.stage > 0 && builder.rust_info().is_managed_git_subrepository() { - let files_to_track = &["src/librustdoc", "src/tools/rustdoc"]; + let files_to_track = &["src/librustdoc", "src/tools/rustdoc", "src/rustdoc-json-types"]; // Check if unchanged if !builder.config.has_changes_from_upstream(files_to_track) { -- cgit 1.4.1-3-g733a5 From 1edf2019370356b81ac60d43899bf7b828771470 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Fri, 30 May 2025 02:29:06 +1000 Subject: Avoid some unnecessary symbol interning. - `Ident::from_str_and_span` -> `Ident::new` when the string is pre-interned. - `Ident::from_str` -> `Ident::with_dummy_span` when the string is pre-interned. - `_d` and `_e` are unused. --- compiler/rustc_builtin_macros/src/alloc_error_handler.rs | 4 ++-- compiler/rustc_builtin_macros/src/autodiff.rs | 6 ++++-- compiler/rustc_hir_pretty/src/lib.rs | 4 ++-- compiler/rustc_span/src/symbol.rs | 3 +-- src/tools/clippy/clippy_lints/src/bool_assert_comparison.rs | 2 +- 5 files changed, 10 insertions(+), 9 deletions(-) (limited to 'src') diff --git a/compiler/rustc_builtin_macros/src/alloc_error_handler.rs b/compiler/rustc_builtin_macros/src/alloc_error_handler.rs index ea406e70666..e75bc944d7e 100644 --- a/compiler/rustc_builtin_macros/src/alloc_error_handler.rs +++ b/compiler/rustc_builtin_macros/src/alloc_error_handler.rs @@ -62,8 +62,8 @@ pub(crate) fn expand( fn generate_handler(cx: &ExtCtxt<'_>, handler: Ident, span: Span, sig_span: Span) -> Stmt { let usize = cx.path_ident(span, Ident::new(sym::usize, span)); let ty_usize = cx.ty_path(usize); - let size = Ident::from_str_and_span("size", span); - let align = Ident::from_str_and_span("align", span); + let size = Ident::new(sym::size, span); + let align = Ident::new(sym::align, span); let layout_new = cx.std_path(&[sym::alloc, sym::Layout, sym::from_size_align_unchecked]); let layout_new = cx.expr_path(cx.path(span, layout_new)); diff --git a/compiler/rustc_builtin_macros/src/autodiff.rs b/compiler/rustc_builtin_macros/src/autodiff.rs index dc3bb8ab52a..df1b1eb60e1 100644 --- a/compiler/rustc_builtin_macros/src/autodiff.rs +++ b/compiler/rustc_builtin_macros/src/autodiff.rs @@ -652,8 +652,10 @@ mod llvm_enzyme { exprs = ecx.expr_call(new_decl_span, bb_call_expr, thin_vec![exprs]); } else { let q = QSelf { ty: d_ret_ty, path_span: span, position: 0 }; - let y = - ExprKind::Path(Some(P(q)), ecx.path_ident(span, Ident::from_str("default"))); + let y = ExprKind::Path( + Some(P(q)), + ecx.path_ident(span, Ident::with_dummy_span(kw::Default)), + ); let default_call_expr = ecx.expr(span, y); let default_call_expr = ecx.expr_call(new_decl_span, default_call_expr, thin_vec![]); diff --git a/compiler/rustc_hir_pretty/src/lib.rs b/compiler/rustc_hir_pretty/src/lib.rs index fc507285860..233bb5cd5b8 100644 --- a/compiler/rustc_hir_pretty/src/lib.rs +++ b/compiler/rustc_hir_pretty/src/lib.rs @@ -22,7 +22,7 @@ use rustc_hir::{ TyPatKind, }; use rustc_span::source_map::SourceMap; -use rustc_span::{FileName, Ident, Span, Symbol, kw}; +use rustc_span::{FileName, Ident, Span, Symbol, kw, sym}; use {rustc_ast as ast, rustc_hir as hir}; pub fn id_to_string(cx: &dyn rustc_hir::intravisit::HirTyCtxt<'_>, hir_id: HirId) -> String { @@ -1517,7 +1517,7 @@ impl<'a> State<'a> { self.bopen(ib); // Print `let _t = $init;`: - let temp = Ident::from_str("_t"); + let temp = Ident::with_dummy_span(sym::_t); self.print_local(false, Some(init), None, |this| this.print_ident(temp)); self.word(";"); diff --git a/compiler/rustc_span/src/symbol.rs b/compiler/rustc_span/src/symbol.rs index 60f3d5fecb0..9924322ae9d 100644 --- a/compiler/rustc_span/src/symbol.rs +++ b/compiler/rustc_span/src/symbol.rs @@ -396,8 +396,7 @@ symbols! { __S, __awaitee, __try_var, - _d, - _e, + _t, _task_context, a32, aarch64_target_feature, diff --git a/src/tools/clippy/clippy_lints/src/bool_assert_comparison.rs b/src/tools/clippy/clippy_lints/src/bool_assert_comparison.rs index ae36bb76117..8f95e44bf85 100644 --- a/src/tools/clippy/clippy_lints/src/bool_assert_comparison.rs +++ b/src/tools/clippy/clippy_lints/src/bool_assert_comparison.rs @@ -56,7 +56,7 @@ fn is_impl_not_trait_with_bool_out<'tcx>(cx: &LateContext<'tcx>, ty: Ty<'tcx>) - .and_then(|trait_id| { cx.tcx.associated_items(trait_id).find_by_ident_and_kind( cx.tcx, - Ident::from_str("Output"), + Ident::with_dummy_span(sym::Output), ty::AssocTag::Type, trait_id, ) -- cgit 1.4.1-3-g733a5 From b95d39d37ae99bca1e9938738ec2c0e3724eefb1 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Tue, 27 May 2025 15:06:56 +1000 Subject: Remove an unnecessary check in rustfmt. "{{root}}" is an internal-only name, and cannot appear in Rust code being formatted. --- src/tools/rustfmt/src/imports.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src') diff --git a/src/tools/rustfmt/src/imports.rs b/src/tools/rustfmt/src/imports.rs index b741dd9b5da..788fed013ad 100644 --- a/src/tools/rustfmt/src/imports.rs +++ b/src/tools/rustfmt/src/imports.rs @@ -184,7 +184,7 @@ impl UseSegment { modsep: bool, ) -> Option { let name = rewrite_ident(context, path_seg.ident); - if name.is_empty() || name == "{{root}}" { + if name.is_empty() { return None; } let kind = match name { -- cgit 1.4.1-3-g733a5 From d475e10dcb1bbd3193edb9968dc9e8f60b7247df Mon Sep 17 00:00:00 2001 From: Jakub Beránek Date: Fri, 20 Jun 2025 08:17:39 +0200 Subject: Add temporary directory for executing snapshot tests --- src/bootstrap/src/core/builder/tests.rs | 5 +-- src/bootstrap/src/utils/tests/mod.rs | 56 ++++++++++++++++++++++++--------- 2 files changed, 45 insertions(+), 16 deletions(-) (limited to 'src') diff --git a/src/bootstrap/src/core/builder/tests.rs b/src/bootstrap/src/core/builder/tests.rs index 1d1c315c1cf..f1af2b285a2 100644 --- a/src/bootstrap/src/core/builder/tests.rs +++ b/src/bootstrap/src/core/builder/tests.rs @@ -1242,12 +1242,13 @@ mod staging { use crate::core::builder::tests::{ TEST_TRIPLE_1, configure, configure_with_args, render_steps, run_build, }; - use crate::utils::tests::ConfigBuilder; + use crate::utils::tests::{ConfigBuilder, TestCtx}; #[test] fn build_compiler_stage_1() { + let ctx = TestCtx::new(); insta::assert_snapshot!( - ConfigBuilder::build() + ctx.config("build") .path("compiler") .stage(1) .get_steps(), @r" diff --git a/src/bootstrap/src/utils/tests/mod.rs b/src/bootstrap/src/utils/tests/mod.rs index ec6293f3c2c..91877fd0da4 100644 --- a/src/bootstrap/src/utils/tests/mod.rs +++ b/src/bootstrap/src/utils/tests/mod.rs @@ -1,25 +1,49 @@ //! This module contains shared utilities for bootstrap tests. +use std::path::{Path, PathBuf}; +use std::thread; + +use tempfile::TempDir; + use crate::core::builder::Builder; use crate::core::config::DryRun; -use crate::{Build, Config, Flags}; +use crate::{Build, Config, Flags, t}; pub mod git; +/// Holds temporary state of a bootstrap test. +/// Right now it is only used to redirect the build directory of the bootstrap +/// invocation, in the future it would be great if we could actually execute +/// the whole test with this directory set as the workdir. +pub struct TestCtx { + directory: TempDir, +} + +impl TestCtx { + pub fn new() -> Self { + let directory = TempDir::new().expect("cannot create temporary directory"); + eprintln!("Running test in {}", directory.path().display()); + Self { directory } + } + + /// Starts a new invocation of bootstrap that executes `kind` as its top level command + /// (i.e. `x `). Returns a builder that configures the created config through CLI flags. + pub fn config(&self, kind: &str) -> ConfigBuilder { + ConfigBuilder::from_args(&[kind], self.directory.path().to_owned()) + } +} + /// Used to configure an invocation of bootstrap. /// Currently runs in the rustc checkout, long-term it should be switched /// to run in a (cache-primed) temporary directory instead. pub struct ConfigBuilder { args: Vec, + directory: PathBuf, } impl ConfigBuilder { - pub fn from_args(args: &[&str]) -> Self { - Self::new(args) - } - - pub fn build() -> Self { - Self::new(&["build"]) + fn from_args(args: &[&str], directory: PathBuf) -> Self { + Self { args: args.iter().copied().map(String::from).collect(), directory } } pub fn path(mut self, path: &str) -> Self { @@ -33,14 +57,18 @@ impl ConfigBuilder { self } - fn new(args: &[&str]) -> Self { - Self { args: args.iter().copied().map(String::from).collect() } - } - pub fn create_config(mut self) -> Config { - let mut config = Config::parse(Flags::parse(&self.args)); // Run in dry-check, otherwise the test would be too slow - config.set_dry_run(DryRun::SelfCheck); - config + self.args.push("--dry-run".to_string()); + + // Ignore submodules + self.args.push("--set".to_string()); + self.args.push("build.submodules=false".to_string()); + + // Do not mess with the local rustc checkout build directory + self.args.push("--build-dir".to_string()); + self.args.push(self.directory.join("build").display().to_string()); + + Config::parse(Flags::parse(&self.args)) } } -- cgit 1.4.1-3-g733a5 From 88f1ed4871887db8b4d96688480bf96666d82005 Mon Sep 17 00:00:00 2001 From: "Chai T. Rex" Date: Fri, 20 Jun 2025 03:37:07 -0400 Subject: Convert `ilog(10)` to `ilog10()` --- library/alloc/src/string.rs | 4 ++-- library/core/src/fmt/num.rs | 8 ++++---- src/librustdoc/html/sources.rs | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) (limited to 'src') diff --git a/library/alloc/src/string.rs b/library/alloc/src/string.rs index 5197e40764b..c200a92e1bd 100644 --- a/library/alloc/src/string.rs +++ b/library/alloc/src/string.rs @@ -2841,7 +2841,7 @@ macro_rules! impl_to_string { impl SpecToString for $signed { #[inline] fn spec_to_string(&self) -> String { - const SIZE: usize = $signed::MAX.ilog(10) as usize + 1; + const SIZE: usize = $signed::MAX.ilog10() as usize + 1; let mut buf = [core::mem::MaybeUninit::::uninit(); SIZE]; // Only difference between signed and unsigned are these 8 lines. let mut out; @@ -2861,7 +2861,7 @@ macro_rules! impl_to_string { impl SpecToString for $unsigned { #[inline] fn spec_to_string(&self) -> String { - const SIZE: usize = $unsigned::MAX.ilog(10) as usize + 1; + const SIZE: usize = $unsigned::MAX.ilog10() as usize + 1; let mut buf = [core::mem::MaybeUninit::::uninit(); SIZE]; self._fmt(&mut buf).to_string() diff --git a/library/core/src/fmt/num.rs b/library/core/src/fmt/num.rs index 13cd7f71094..42af595ae41 100644 --- a/library/core/src/fmt/num.rs +++ b/library/core/src/fmt/num.rs @@ -208,7 +208,7 @@ macro_rules! impl_Display { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { #[cfg(not(feature = "optimize_for_size"))] { - const MAX_DEC_N: usize = $unsigned::MAX.ilog(10) as usize + 1; + const MAX_DEC_N: usize = $unsigned::MAX.ilog10() as usize + 1; // Buffer decimals for $unsigned with right alignment. let mut buf = [MaybeUninit::::uninit(); MAX_DEC_N]; @@ -226,7 +226,7 @@ macro_rules! impl_Display { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { #[cfg(not(feature = "optimize_for_size"))] { - const MAX_DEC_N: usize = $unsigned::MAX.ilog(10) as usize + 1; + const MAX_DEC_N: usize = $unsigned::MAX.ilog10() as usize + 1; // Buffer decimals for $unsigned with right alignment. let mut buf = [MaybeUninit::::uninit(); MAX_DEC_N]; @@ -323,7 +323,7 @@ macro_rules! impl_Display { #[cfg(feature = "optimize_for_size")] fn $gen_name(mut n: $u, is_nonnegative: bool, f: &mut fmt::Formatter<'_>) -> fmt::Result { - const MAX_DEC_N: usize = $u::MAX.ilog(10) as usize + 1; + const MAX_DEC_N: usize = $u::MAX.ilog10() as usize + 1; let mut buf = [MaybeUninit::::uninit(); MAX_DEC_N]; let mut curr = MAX_DEC_N; let buf_ptr = MaybeUninit::slice_as_mut_ptr(&mut buf); @@ -565,7 +565,7 @@ mod imp { } impl_Exp!(i128, u128 as u128 via to_u128 named exp_u128); -const U128_MAX_DEC_N: usize = u128::MAX.ilog(10) as usize + 1; +const U128_MAX_DEC_N: usize = u128::MAX.ilog10() as usize + 1; #[stable(feature = "rust1", since = "1.0.0")] impl fmt::Display for u128 { diff --git a/src/librustdoc/html/sources.rs b/src/librustdoc/html/sources.rs index 1fa6b5a60f3..c34b3154269 100644 --- a/src/librustdoc/html/sources.rs +++ b/src/librustdoc/html/sources.rs @@ -353,7 +353,7 @@ pub(crate) fn print_src( ); Ok(()) }); - let max_nb_digits = if lines > 0 { lines.ilog(10) + 1 } else { 1 }; + let max_nb_digits = if lines > 0 { lines.ilog10() + 1 } else { 1 }; match source_context { SourceContext::Standalone { file_path } => Source { code_html: code, -- cgit 1.4.1-3-g733a5