diff --git a/src/doc/rustc-dev-guide/rust-version b/src/doc/rustc-dev-guide/rust-version index a05eac34eb1e9..f930573748e28 100644 --- a/src/doc/rustc-dev-guide/rust-version +++ b/src/doc/rustc-dev-guide/rust-version @@ -1 +1 @@ -8c75e93c5c7671c29f3e8c096b7acf56822ed23a +7fb284d9037fa54f6a9b24261c82b394472cbfd7 diff --git a/src/doc/rustc-dev-guide/src/SUMMARY.md b/src/doc/rustc-dev-guide/src/SUMMARY.md index d414f374b36cb..bf2de84575d69 100644 --- a/src/doc/rustc-dev-guide/src/SUMMARY.md +++ b/src/doc/rustc-dev-guide/src/SUMMARY.md @@ -193,6 +193,7 @@ - [Sharing the trait solver with rust-analyzer](./solve/sharing-crates-with-rust-analyzer.md) - [`Unsize` and `CoerceUnsized` traits](./traits/unsize.md) - [Having separate `Trait` and `Projection` bounds](./traits/separate-projection-bounds.md) +- [Well-formedness](./analysis/well-formed.md) - [Variance](./variance.md) - [Coherence checking](./coherence.md) - [HIR Type checking](./hir-typeck/summary.md) diff --git a/src/doc/rustc-dev-guide/src/analysis/well-formed.md b/src/doc/rustc-dev-guide/src/analysis/well-formed.md new file mode 100644 index 0000000000000..4a2450a480ed2 --- /dev/null +++ b/src/doc/rustc-dev-guide/src/analysis/well-formed.md @@ -0,0 +1,326 @@ +# Well-formedness + +## What is well-formedness? + +"Well-formed" means "correctly built"[^wf-history]. +Something is _well-formed_ when its structure follows rules. +When we use this term in the Rust compiler we are concerned with establishing some kind of _internal consistency_. + +## Well-formedness in Rust + +To check that something is well-formed is to perform a "Well-formedness check". + +In the Rust compiler there are two different forms of well-formedness checking: + +- **Type-Level Term**[^terms][^terms-abbreviated] well-formedness check. + - Also called "Term well-formedness" or "Term well-formedness checking". + - Not a distinct analysis stage, this gets performed throughout analysis. +- **Item**[^items] well-formedness check (item-wfck.) + - "Item-wfck" will often wind up requiring Terms be well-formed, but skips some areas. + - Inner "Terms" can (incorrectly) get normalized first. + - More coherent as a stage in the compiler than "term well-formedness" (which is performed in many places.) + +See: [What Well-Formedness Isn't](#what-well-formedness-isnt). + +## Well-formedness of type-level terms + +Term well-formedness checking begins with building a list of things that need to be true for a term to be well-formed. +We call these "Obligations"[^obligations]. + +Type-Level Terms are considered well-formed when their associated obligations are satisfied by the trait solver. + +### Obligations for well-formedness + +Specific obligations are things like `String: Clone`, `A: usize`, or `::Item: Debug`. + +On this page we show the split between obligations and terms/items as: + +```rust,ignore + +--- + +``` + +Here is an example of a well-formed type-level term: + +```rust,ignore +Vec +--- +// Obligations to fulfill +Vec where T: Sized +// Trait solver says `String: Sized` is true, so this is well-formed. +Vec where String: Sized +``` + +When we compute the obligations for `Vec`, we'll find that `Vec` generates the obligation `T: Sized`. +We substitute `T` with `String` in `Vec`, so we find the obligation `String: Sized` which the trait solver will determine to be satisfied. + +The following **is not** well-formed: + +```rust,ignore +Vec +--- +// Obligations to fulfill +Vec where T: Sized +// Trait solver says `str: Sized` is not true, so this is not well-formed. +Vec where str: Sized +``` + +The above computes the obligation `T: Sized`, like before, but we substitute `T` for `str` in the instance of `Vec` finding the obligation `str: sized`. +This obligation will be determined by the trait solver to be _unsatisfied_. + +#### Determining obligations + +In the compiler, obligations of terms are found through the [`obligations`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/wf/fn.obligations.html) function in the [term well-formedness module](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/wf/index.html). + +#### Other obligations + +Obligations are more than just trait and const generic bounds, but we've only mentioned these specific obligations so far as they are what we care about when we do "well-formedness checking" of terms. +See: [`PredicateKind`](https://doc.rust-lang.org/beta/nightly-rustc/rustc_type_ir/predicate_kind/enum.PredicateKind.html) and [`ClauseKind`](https://doc.rust-lang.org/beta/nightly-rustc/rustc_type_ir/predicate_kind/enum.ClauseKind.html) for a full list of obligations. + +### We don't need normalization (yet) + +[Normalization](../normalization.md) is the process of resolving [type aliases](../normalization.md#aliases) into their underlying type. + +A type alias is considered well-formed if its where clauses are satisfied. +The underlying type undergoes well-formedness checking at most definition and instantiation sites, but there are exceptions. + +### Const generic arguments + +Term well-formedness is responsible for getting "type checking" obligations of const generic terms[^tyck-const-generics]. +Let's look at the following use of const generics: + +```rust,ignore +fn use_const_generics() { /* ... */ } +// call site +use_const_generics::<6>(); +--- +// call site wfck obligations +const 6: usize +``` + +The call site will provide us with the obligation `6: usize` during well-formedness checking. +This obligation will be passed off to the trait solver just like any trait-style obligation, as the trait solver has more responsibilities than its name suggests. + +## Well-formedness of items + +Items are, generally speaking, "Things that get defined". +Item-wfck happens at the signature level for types and functions, methods, and definitions/implementations of traits. + +```rust,ignore +// The `Vec` is checked during item wfck +fn foo(_: Vec) { + // The `Vec<[u8]>` is not handled by item wfck as it's not in the signature + let _: Vec<[u8]> +} +--- +Vec: Sized // Generated +Vec<[u8]>: Sized // Not done at item-wfck. Done elsewhere. +``` + +Item-wfck has more responsibilities than only collecting the obligations of its internal type-level terms and passing them to the trait solver. +We do not talk about all of these here, but they can be found at the individual `check_*` functions in [**the item-wfck module**](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/check/wfcheck/index.html). + + + +### Global and trivial bounds + + + +Trait bounds are a common Obligation. +Global and Trivial trait bounds are kinds of trait bounds where we already have enough information to determine if they are true or false. +Item-wfck is responsible for finding and checking these bounds. + +- **Global bounds** are, in the old solver, post-normalization bounds that don't contain any generic parameters (like `` or `'a`) or bound variables (like `for<'b>`). +- **Trivial bounds** are bounds that do not need further normalization to determine if they're well-formed or not. + +Consider the following function definition: + +```rust,ignore +fn apartment_complex(block: T, name: String) where String: Clone { /* ... */ } +--- +String: Clone // Trivial & Global bound! There's no aliases to resolve. +// There could be bligations on T but we don't care about them here. +``` + +This produces a trait bound obligation `String: Clone` that is _Global_ (no generic parameters) and _Trivial_ (didn't require normalization to be well-formedness checked). +The trait solver doesn't need to be given any additional information for it to be able to make a judgment on the well-formedness of `String: Clone`. + +False trivial bounds are simply trivial bounds that do not hold. +The following is a basic example: + +```rust,ignore +fn apartment_simple(block: T, name: String) where String: Copy { /* ... */ } +--- +String: Copy // Trivial bound again, but this one is false! +``` + +Here we have a trivial bound that does not hold, because `String` is not `Copy`. + +#### Trivial bounds are not always global + +Trivial Bounds are not a subset of Global Bounds. +A trivial bound that isn't Global is `for<'a> String: Clone` (trivially true, has a bound variable) or `&'a str: Copy` (trivially false, has a generic parameter). + +#### Item-wfck and trivial/global bounds + + + +When checking items are well-formed we will check that there are no trivially false global bounds. + +## When we don't fully do well-formedness checking + +Well-formedness checking is not a coherent "stage" of type checking. +There are many areas where well-formedness checking is performed, and some areas where we skip over well-formedness checking due to limitations in what kinds of analysis we can currently perform. +Ideally, we would never skip or defer well-formedness checking. + +### We (sometimes) need normalization + +There are places where normalization of an Item happens before its Terms have gone through well-formedness checking. +This is considered problematic as doing so allows some terms to [bypass term well-formedness checking entirely](https://github.com/rust-lang/rust/issues/100041). + +### Trait objects + +We do not require the where clauses of trait objects to be well-formed when determining if that trait object is well-formed. +These where clauses are proven when coercing into a trait object, but this remains a hole in well-formedness checking. + +As an example, the following will compile because we don't have a point where we're constructing the trait object from a concrete type: + +```rust,ignore +trait Trait +where + for<'a> [u8]: Sized {} + +fn foo(_: &dyn Trait) {} +--- +// This doesn't end up being generated, because it happens within a trait object. +[u8]: Sized +``` + +The above should not compile because `[u8]: Sized`, but this won't be checked until actual use: + +```rust +trait Trait +where + for<'a> [u8]: Sized {} + +fn foo(_: &dyn Trait) {} + +// We still need to specify the bound here, otherwise `[u8]: Sized` _is_ +// checked as an obligation. +impl Trait for u8 where for<'a> [u8]: Sized {} + +fn main() { + // No matter what we do, this boundary between concrete type and trait + // object will produce the obligation `[u8]: Sized`, which will fail when + // handed over to the trait solver. + let object: Box = Box::new(42u8); + foo(&object); +} +``` + +This exception does not apply to Const Generic Arguments in trait objects: + +```rust,ignore +trait Trait {} +fn foo(_: &dyn Trait) {} +--- +const N: usize +const B: bool +N = B // Substitution +const B: usize + bool +``` + +The above doesn't compile, unlike the previous example we gave. +We're doing _some_ well-formedness checking here when it comes to the const generic arguments. + +### Binders / higher-ranked types + +Binders / Higher-Ranked Types reduce the amount well-formedness checking we do on a term, leaving well-formedness checking to when the bound is instantiated: + +```rust,ignore +let _: for<'a> fn(Vec<[&'a ()]>); +--- +// This doesn't end up being generated, because it happens within a HRB +[&'a ()]: Sized // slices aren't sized, this would fail! +``` + +Specifically, obligations involving variables from binders (`for<'a>`) are only checked when the binder is instantiated. +Some things are stilled checked under the `for<'a>`, but we still skip a lot of things. + +A lot of unsoundness surrounds this behavior. +See: [#25860](https://github.com/rust-lang/rust/issues/25860), [#84591](https://github.com/rust-lang/rust/issues/84591). + +Let's consider the following: + +```rust,ignore +for<'a, 'b> fn(&'a &'b ()) +``` + +The above HRB implies `'b: 'a` (a lifetime bound), rather than two completely separate lifetimes. +This is normal lifetime behavior, but during well-formedness checking we cannot prove that this bound is generally true[^horrible], so we skip it. + +### Free type aliases + +The right-hand side of Free Type Aliases[^fta] is not fully checked to be well-formed at the definition site, only the types of const generic arguments in the RHS are checked. + +The following free type alias passes type checking, at time of writing: + +```rust,ignore +type WorksButShouldNot = Vec; +--- +// This should fail! But we skip the RHS of free type aliases +str: Sized // Not generated +``` + +This shouldn't work, as both `T: Sized`, `str: Sized` are implied by `Vec`. +This "passes" item-wfck because the RHS of a free type alias doesn't go through well-formedness checking _until it's used_. +Item-wfck is **deferred until use** for this specific case. + +For Const Generics we still do a small amount of well-formedness checking at the definition site of a free type alias. +This is consistent with our current special-casing of const generic well-formedness checking when we skip over things like where bounds. + +This means that the following, despite being of a similar form to the above example, fails as it should: + +```rust,ignore +pub struct Consty; +type Alias = Consty<42>; +--- +// This *is* generated as an obligation, so this (correctly) fails. +42: bool // This is generated! +``` + + + +## "well-formed" or "wellformed"? + +Prefer "well-formed" over "wellformed", as this is consistent with logic literature. +This also gets abbreviated to WF in other parts of the dev guide / docs. + +## Informal usage + +In conversation, contributors may refer to something as "well-formed" and not necessarily mean what we cover here because "well-formedness" is a general phrase associated with the correctness of formal structures. +This isn't necessarily in error, but it should be looked out for. + +## What well-formedness isn't + +Well-formedness checking is not "number of parameters" or "parameter type" checking[^kind-checking]. +Neither term well-formedness checking nor item-wfck is concerned with if a type with 2 parameters has 1 or 3 types applied to it (assuming no defaults), or if a const generic parameter has a type applied to it. +These kinds of problems will get handled during HIR-ty Lowering[^hir-ty-lower], not wfck. + +Well-formedness doesn't check or validate lifetimes, this is handled in [MIR](../borrow-check.md). + +Well-formedness in the Rust compiler doesn't correspond to "correct syntax" as it does in logic. +The term has a history of general use in a mathematical context of "follows a given set of rules". +In Rust, our original usage was closer to "this thing is internally consistent" with respect to the bounds on a type in places such as the original [clarification on projections and well-formedness RFC](https://github.com/rust-lang/rfcs/blob/master/text/1214-projections-lifetimes-and-wf.md). + +[^obligations]: These get referred to as Obligations, Requirements, or Constraints in the documentation. Preferred term is "obligations", as this matches the suffix of the type and the names of relevant functions. In future, this may be superseded by the new solver's term "Goal". +[^wf-history]: In linguistics this is "grammatically correct", in logic it is "syntactically correct", and in casual mathematician use it can be read as a more general "follows the rules we set for this domain". +[^horrible]: Instead, this bound is checked during "MIR borrowck" when the lifetimes are instantiated. +[^fta]: Type aliases not associated with anything, i.e. a module-level `type Alias = Vec;`. +[^items]: "Definition" style things in rust, See the [glossary](../appendix/glossary.md). +[^terms]: AKA Type expressions and subexpressions in the general sense, not a specific struct or enum in the rust compiler. See the [glossary](../appendix/glossary.md). +[^terms-abbreviated]: Abbreviated as "Terms" on this page in some areas. +[^kind-checking]: AKA "kind checking", as we might see in languages like Haskell. +[^hir-ty-lower]: +[^tyck-const-generics]: #checking-types-of-const-arguments diff --git a/src/doc/rustc-dev-guide/src/appendix/glossary.md b/src/doc/rustc-dev-guide/src/appendix/glossary.md index 30959f4b39e6f..527da87b7b7e1 100644 --- a/src/doc/rustc-dev-guide/src/appendix/glossary.md +++ b/src/doc/rustc-dev-guide/src/appendix/glossary.md @@ -102,6 +102,7 @@ Term | Meaning trans 👎 | Short for _translation_, the code to translate MIR into LLVM IR. **Renamed to** [codegen](#codegen). `Ty` | The internal representation of a type. ([see more](../ty.md)) `TyCtxt` | The data structure often referred to as [`tcx`](#tcx) in code which provides access to session data and the query system. +Type-Level Term | An expression at the type level, such as a Type or Const Generic. UFCS 👎 | Short for _universal function call syntax_, this is an unambiguous syntax for calling a method. **Term no longer in use!** Prefer _fully-qualified path / syntax_. ([see more](../hir-typeck/summary.md), [see the reference](https://doc.rust-lang.org/reference/expressions/call-expr.html#disambiguating-function-calls)) uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called _empty types_. upvar | A variable captured by a closure from outside the closure. diff --git a/src/doc/rustc-dev-guide/src/autodiff/installation.md b/src/doc/rustc-dev-guide/src/autodiff/installation.md index 7247efd46a380..4176763a7bd62 100644 --- a/src/doc/rustc-dev-guide/src/autodiff/installation.md +++ b/src/doc/rustc-dev-guide/src/autodiff/installation.md @@ -18,30 +18,30 @@ Please run: rustup +nightly component add enzyme ``` -## Installation guide for Nix user. +## Installation guide for Nix + +On [Nix], you can declare a nightly Rust toolchain with the Enzyme component using the [oxalica rust-overlay]. + +For example: + +```nix +rust-bin.selectLatestNightlyWith (toolchain: toolchain.default.override { + extensions = [ "enzyme" ]; +}) +``` + +Alternatively, you can create a [toolchain file] that declares the Enzyme component such as + +```toml +[toolchain] +channel = "nightly-2026-06-23" +components = [ "enzyme" ] +``` + +and consume it in the overlay -This setup was recommended by a nix and autodiff user. -It uses [`Overlay`]. -Please verify for yourself if you are comfortable using that repository. -In that case you might use the following nix configuration to get a rustc that supports `std::autodiff`. ```nix -{ - enzymeLib = pkgs.fetchzip { - url = "https://ci-artifacts.rust-lang.org/rustc-builds/ec818fda361ca216eb186f5cf45131bd9c776bb4/enzyme-nightly-x86_64-unknown-linux-gnu.tar.xz"; - sha256 = "sha256-Rnrop44vzS+qmYNaRoMNNMFyAc3YsMnwdNGYMXpZ5VY="; - }; - - rustToolchain = pkgs.symlinkJoin { - name = "rust-with-enzyme"; - paths = [pkgs.rust-bin.nightly.latest.default]; - nativeBuildInputs = [pkgs.makeWrapper]; - postBuild = '' - libdir=$out/lib/rustlib/x86_64-unknown-linux-gnu/lib - cp ${enzymeLib}/enzyme-preview/lib/rustlib/x86_64-unknown-linux-gnu/lib/libEnzyme-22.so $libdir/ - wrapProgram $out/bin/rustc --add-flags "--sysroot $out" - ''; - }; -} +rust-bin.fromRustupToolchainFile ./rust-toolchain.toml ``` ## Build instructions @@ -135,4 +135,6 @@ This will build Enzyme, and you can find it in `Enzyme/enzyme/build/lib//bootstrap-trace/` directory. For convenience, bootstrap will also create a symlink to the latest generated trace output directory at `/bootstrap-trace/latest`. +The structured logs will be written to standard error output (`stderr`), while the other outputs will be stored in files in the `/bootstrap-trace/` directory. +For convenience, bootstrap will also create a symlink to the latest generated trace output directory at `/bootstrap-trace/latest`. > Note that if you execute bootstrap with `--dry-run`, the tracing output directory might change. Bootstrap will always print a path where the tracing output files were stored at the end of its execution. @@ -73,18 +77,24 @@ Build completed successfully in 0:00:00 #### Controlling tracing output -The environment variable `BOOTSTRAP_TRACING` accepts a [`tracing_subscriber` filter][tracing-env-filter]. If you set `BOOTSTRAP_TRACING=trace`, you will enable all logs, but that can be overwhelming. You can thus use the filter to reduce the amount of data logged. +The environment variable `BOOTSTRAP_TRACING` accepts a [`tracing_subscriber` filter][tracing-env-filter]. +If you set `BOOTSTRAP_TRACING=trace`, you will enable all logs, but that can be overwhelming. +You can thus use the filter to reduce the amount of data logged. There are two orthogonal ways to control which kind of tracing logs you want: 1. You can specify the log **level**, e.g. `debug` or `trace`. - If you select a level, all events/spans with an equal or higher priority level will be shown. 2. You can also control the log **target**, e.g. `bootstrap` or `bootstrap::core::config` or a custom target like `CONFIG_HANDLING` or `STEP`. - - Custom targets are used to limit what kinds of spans you are interested in, as the `BOOTSTRAP_TRACING=trace` output can be quite verbose. Currently, you can use the following custom targets: + - Custom targets are used to limit what kinds of spans you are interested in, as the `BOOTSTRAP_TRACING=trace` output can be quite verbose. + Currently, you can use the following custom targets: - `CONFIG_HANDLING`: show spans related to config handling. - - `STEP`: show all executed steps. Executed commands have `info` event level. - - `COMMAND`: show all executed commands. Executed commands have `trace` event level. - - `IO`: show performed I/O operations. Executed commands have `trace` event level. + - `STEP`: show all executed steps. + Executed commands have `info` event level. + - `COMMAND`: show all executed commands. + Executed commands have `trace` event level. + - `IO`: show performed I/O operations. + Executed commands have `trace` event level. - Note that many I/O are currently not being traced. You can of course combine them (custom target logs are typically gated behind `TRACE` log level additionally): @@ -100,14 +110,15 @@ Note that the level that you specify using `BOOTSTRAP_TRACING` also has an effec ##### FIXME(#96176): specific tracing for `compiler()` vs `compiler_for()` The additional targets `COMPILER` and `COMPILER_FOR` are used to help trace what -`builder.compiler()` and `builder.compiler_for()` does. They should be removed -if [#96176][cleanup-compiler-for] is resolved. +`builder.compiler()` and `builder.compiler_for()` does. +They should be removed if [#96176][cleanup-compiler-for] is resolved. [cleanup-compiler-for]: https://github.com/rust-lang/rust/issues/96176 ### Using `tracing` in bootstrap -Both `tracing::*` macros and the `tracing::instrument` proc-macro attribute need to be gated behind `tracing` feature. Examples: +Both `tracing::*` macros and the `tracing::instrument` proc-macro attribute need to be gated behind `tracing` feature. +Examples: ```rs #[cfg(feature = "tracing")] diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping/how-bootstrap-does-it.md b/src/doc/rustc-dev-guide/src/building/bootstrapping/how-bootstrap-does-it.md index 4d301b3abae1a..63c154d25d22f 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping/how-bootstrap-does-it.md +++ b/src/doc/rustc-dev-guide/src/building/bootstrapping/how-bootstrap-does-it.md @@ -1,14 +1,16 @@ # How Bootstrap does it The core concept in Bootstrap is a build [`Step`], which are chained together -by [`Builder::ensure`]. [`Builder::ensure`] takes a [`Step`] as input, and runs -the [`Step`] if and only if it has not already been run. Let's take a closer -look at [`Step`]. +by [`Builder::ensure`]. +[`Builder::ensure`] takes a [`Step`] as input, and runs +the [`Step`] if and only if it has not already been run. +Let's take a closer look at [`Step`]. ## Synopsis of [`Step`] A [`Step`] represents a granular collection of actions involved in the process -of producing some artifact. It can be thought of like a rule in Makefiles. +of producing some artifact. +It can be thought of like a rule in Makefiles. The [`Step`] trait is defined as: ```rs,no_run @@ -30,8 +32,8 @@ pub trait Step: 'static + Clone + Debug + PartialEq + Eq + Hash { - `run` is the function that is responsible for doing the work. [`Builder::ensure`] invokes `run`. - `should_run` is the command-line interface, which determines if an invocation - such as `x build foo` should run a given [`Step`]. In a "default" context - where no paths are provided, then `make_run` is called directly. + such as `x build foo` should run a given [`Step`]. + In a "default" context where no paths are provided, then `make_run` is called directly. - `make_run` is invoked only for things directly asked via the CLI and not for steps which are dependencies of other steps. diff --git a/src/doc/rustc-dev-guide/src/building/bootstrapping/intro.md b/src/doc/rustc-dev-guide/src/building/bootstrapping/intro.md index 7f53097824cc9..e4704a10e0a78 100644 --- a/src/doc/rustc-dev-guide/src/building/bootstrapping/intro.md +++ b/src/doc/rustc-dev-guide/src/building/bootstrapping/intro.md @@ -1,14 +1,13 @@ # Bootstrapping the compiler -[*Bootstrapping*][boot] is the process of using a compiler to compile itself. -More accurately, it means using an older compiler to compile a newer version -of the same compiler. +[*Bootstrapping*] is the process of using a compiler to compile itself. +More accurately, it means using an older compiler to compile a newer version of the same compiler. This raises a chicken-and-egg paradox: where did the first compiler come from? -It must have been written in a different language. In Rust's case it was -[written in OCaml][ocaml-compiler]. However, it was abandoned long ago, and the -only way to build a modern version of rustc is with a slightly less modern -version. +It must have been written in a different language. +In Rust's case it was [written in OCaml]. +However, it was abandoned long ago, and the +only way to build a modern version of rustc is with a slightly less modern version. This is exactly how `x.py` works: it downloads the current beta release of rustc, then uses it to compile the new compiler. @@ -17,8 +16,7 @@ In this section, we give a high-level overview of [what Bootstrap does](./what-bootstrapping-does.md), followed by a high-level introduction to [how Bootstrap does it](./how-bootstrap-does-it.md). -Additionally, see [debugging bootstrap](./debugging-bootstrap.md) to learn -about debugging methods. +Additionally, see [debugging bootstrap](./debugging-bootstrap.md) to learn about debugging methods. -[boot]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) -[ocaml-compiler]: https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216f8aaa5b388d98da6480/src/boot +[*Bootstrapping*]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) +[written in OCaml]: https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216f8aaa5b388d98da6480/src/boot diff --git a/src/doc/rustc-dev-guide/src/compiler-debugging.md b/src/doc/rustc-dev-guide/src/compiler-debugging.md index a07b418c64d4d..49a965d49df33 100644 --- a/src/doc/rustc-dev-guide/src/compiler-debugging.md +++ b/src/doc/rustc-dev-guide/src/compiler-debugging.md @@ -236,7 +236,7 @@ The compiler uses the [`tracing`] crate for logging. For details, see [the chapter on tracing](./tracing.md). -## Narrowing (Bisecting) Regressions +## Narrowing (bisecting) regressions The [cargo-bisect-rustc][bisect] tool can be used as a quick and easy way to find exactly which PR caused a change in `rustc` behavior. @@ -248,7 +248,7 @@ You can then look at the PR to get more context on *why* it was changed. [bisect]: https://github.com/rust-lang/cargo-bisect-rustc [bisect-tutorial]: https://rust-lang.github.io/cargo-bisect-rustc/tutorial.html -## Downloading Artifacts from Rust's CI +## Downloading artifacts from Rust's CI The [rustup-toolchain-install-master][rtim] tool by kennytm can be used to download the artifacts produced by Rust's CI for a specific SHA1 -- this diff --git a/src/doc/rustc-dev-guide/src/contributing.md b/src/doc/rustc-dev-guide/src/contributing.md index 4e292c5476d1c..5cbffb1a49eee 100644 --- a/src/doc/rustc-dev-guide/src/contributing.md +++ b/src/doc/rustc-dev-guide/src/contributing.md @@ -257,7 +257,7 @@ In particular, we don't recommend running the full `./x test` suite locally, since it takes a very long time to execute. See the [Testing with CI] chapter for using Rust's CI to test your changes. -[Testing with CI]: https://rustc-dev-guide.rust-lang.org/tests/ci.html#testing-with-ci +[Testing with CI]: tests/ci.md#testing-with-ci ### r+ @@ -425,7 +425,7 @@ Just a few things to keep in mind: - When contributing text to the guide, please contextualize the information with some time period and/or a reason so that the reader knows how much to trust the information. - Aim to provide a reasonable amount of context, possibly including but not limited to: + Aim to provide a reasonable amount of context, and consider including: - A reason for why the text may be out of date other than "change", as change is a constant across the project. @@ -444,29 +444,29 @@ Just a few things to keep in mind: For the action to pick the date, add a special annotation before specifying the date: ```md - Nov 2025 + Jul 2026 ``` Example: ```md - As of Nov 2025, the foo did the bar. + As of Jul 2026, the foo did the bar. ``` For cases where the date should not be part of the visible rendered output, use the following instead: ```md - + ``` - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide further explanation for the change process or a way to verify that the information is not outdated. -- If a text grows rather long (more than a few page scrolls) or complicated (more than four - subsections), it might benefit from having a Table of Contents at the beginning, - which you can auto-generate by including the `` marker at the top. +- Use sentence case for chapter and sections titles. + +- Use dashes (`-`) to separate words file names. #### ⚠️ Note: Where to contribute `rustc-dev-guide` changes diff --git a/src/doc/rustc-dev-guide/src/offload/installation.md b/src/doc/rustc-dev-guide/src/offload/installation.md index 4b67f31cd3c28..ab8e7984d5b4a 100644 --- a/src/doc/rustc-dev-guide/src/offload/installation.md +++ b/src/doc/rustc-dev-guide/src/offload/installation.md @@ -44,7 +44,7 @@ Run this test script for offload-specific tests: ./x test --stage 1 tests/codegen-llvm/gpu_offload ``` -For testing the CI locally, you may use the commands outlined in [Testing with Docker](https://rustc-dev-guide.rust-lang.org/tests/docker.html): +For testing the CI locally, you may use the commands outlined in [Testing with Docker](../tests/docker.md): ```console cargo run --manifest-path src/ci/citool/Cargo.toml run-local dist-x86_64-linux ``` diff --git a/src/doc/rustc-dev-guide/src/tests/best-practices.md b/src/doc/rustc-dev-guide/src/tests/best-practices.md index b6daffa6683c0..d1378a849a9d4 100644 --- a/src/doc/rustc-dev-guide/src/tests/best-practices.md +++ b/src/doc/rustc-dev-guide/src/tests/best-practices.md @@ -171,7 +171,7 @@ place. If a test suite can randomly spuriously fail due to flaky tests, did the whole test suite pass or did I just get lucky/unlucky? -- Flaky tests can randomly fail in full CI, wasting previous full CI resources. +- Flaky tests can randomly fail in full CI, wasting precious resources. ## Compiletest directives diff --git a/src/doc/rustc-dev-guide/src/tests/ci.md b/src/doc/rustc-dev-guide/src/tests/ci.md index 8f06d69d8cffe..31c6949d85d6c 100644 --- a/src/doc/rustc-dev-guide/src/tests/ci.md +++ b/src/doc/rustc-dev-guide/src/tests/ci.md @@ -209,7 +209,7 @@ to help make the perf comparison as fair as possible. > > 3. Run the prescribed try jobs with `@bors try`. As aforementioned, this > requires the user to either (1) have `try` permissions or (2) be delegated -> with `try` permissions by `@bors delegate=try` by someone who has `try` +> with `try` permissions by `@bors delegate try` by someone who has `try` > permissions. > > Note that this is usually easier to do than manually edit [`jobs.yml`]. diff --git a/src/doc/rustc-dev-guide/src/traits/separate-projection-bounds.md b/src/doc/rustc-dev-guide/src/traits/separate-projection-bounds.md index 144e27316cbb4..94a0d752c945b 100644 --- a/src/doc/rustc-dev-guide/src/traits/separate-projection-bounds.md +++ b/src/doc/rustc-dev-guide/src/traits/separate-projection-bounds.md @@ -8,7 +8,7 @@ The way we prove `Projection` bounds directly relies on proving the correspondin It feels like it might make more sense to just have a single implementation which checks whether a trait is implemented and returns (a way to compute) its associated types. This is unfortunately quite difficult, as we may use a different candidate for norm than for the corresponding trait bound. -See [alias-bound vs where-bound](https://rustc-dev-guide.rust-lang.org/solve/candidate-preference.html#we-always-consider-aliasbound-candidates) and [global where-bound vs impl](https://rustc-dev-guide.rust-lang.org/solve/candidate-preference.html#we-prefer-global-where-bounds-over-impls). +See [alias-bound vs where-bound](../solve/candidate-preference.md#we-always-consider-aliasbound-candidates) and [global where-bound vs impl](../solve/candidate-preference.md#we-prefer-global-where-bounds-over-impls). There are also some other subtle reasons for why we can't do so. The most stupid is that for rigid aliases;