(x: *mut [T; 256], value: T) {
unsafe {
let n = (*x).len();
let i = (thread_idx_x() + block_idx_x() * block_dim_x()) as usize;
if i < n {
- (*x)[i] = i as f64;
+ (*x)[i] = value;
}
}
}
@@ -45,9 +48,13 @@ fn kernel(x: *mut [f64; 256]) {
#[unsafe(no_mangle)]
fn main() {
let mut x = [0.0f64; 256];
- core::intrinsics::offload::<_, _, ()>(kernel, [256, 1, 1], [1, 1, 1], (&mut x as *mut [f64; 256],));
+ core::offload::offload! {
+ kernel = kernel,
+ workgroup_dim = [256, 1, 1],
+ args = (&mut x as *mut [f64; 256], 2.5),
+ }
for i in 0..x.len() {
- assert_eq!(x[i], i as f64);
+ assert_eq!(x[i], 2.5);
}
unsafe { libc::printf(c"all checks passed".as_ptr()); }
}
@@ -58,7 +65,12 @@ 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.
So either substitute clang/lld invocations below with absolute path, or set your `PATH` accordingly.
-First we generate the device (GPU) code.
+The compilation runs three passes:
+1. `HostMetadata`: compile the host code, writing a manifest that lists the kernel
+ instantiations (including generic ones) required by the host code.
+2. `Device`: compile the kernels for the GPU, reading the manifest so the recorded generic
+ instantiations are codegened.
+3. `Host`: generate the final host code, embedding the device artifact.
@@ -67,8 +79,15 @@ These are often referred to as "LLVM target names"[^list].
+First we generate the manifest from the host code:
+```
+RUSTFLAGS="--emit=llvm-bc,llvm-ir -Csave-temps -Zoffload=HostMetadata=/absolute/path/to/offload.manifest -Zunstable-options" cargo +offload build -r
+```
+This pass only writes the manifest.
+
+Now we generate the device (GPU) code, passing the manifest:
```
-RUSTFLAGS="-Ctarget-cpu=gfx90a --emit=llvm-bc,llvm-ir -Zoffload=Device -Csave-temps -Zunstable-options" cargo +offload build -Zunstable-options -r -v --target amdgcn-amd-amdhsa -Zbuild-std=core
+RUSTFLAGS="-Ctarget-cpu=gfx90a --emit=llvm-bc,llvm-ir -Zoffload=Device=/absolute/path/to/offload.manifest -Csave-temps -Zunstable-options" cargo +offload build -Zunstable-options -r -v --target amdgcn-amd-amdhsa -Zbuild-std=core
```
You might afterwards need to copy your target/release/deps/.bc to lib.bc for now, before the next step.
diff --git a/src/doc/rustc-dev-guide/src/opaque-types-impl-trait-inference.md b/src/doc/rustc-dev-guide/src/opaque-types-impl-trait-inference.md
index ac908493ee564..b9f10ec5700ce 100644
--- a/src/doc/rustc-dev-guide/src/opaque-types-impl-trait-inference.md
+++ b/src/doc/rustc-dev-guide/src/opaque-types-impl-trait-inference.md
@@ -5,7 +5,7 @@ This kind of type inference is particularly complex because,
unlike other kinds of type inference,
it can work across functions and function bodies.
-[hidden type]: ./borrow-check/region-inference/member-constraints.html?highlight=%22hidden%20type%22#member-constraints
+[hidden type]: ./borrow-check/region-inference/member-constraints.md?highlight=%22hidden%20type%22#member-constraints
[opaque type]: ./opaque-types-type-alias-impl-trait.md
## Running example
diff --git a/src/doc/rustc-dev-guide/src/part-4-intro.md b/src/doc/rustc-dev-guide/src/part-4-intro.md
index 6a84331641757..db692012cfbe3 100644
--- a/src/doc/rustc-dev-guide/src/part-4-intro.md
+++ b/src/doc/rustc-dev-guide/src/part-4-intro.md
@@ -1,12 +1,14 @@
# Analysis
This part discusses the many analyses that the compiler uses to check various
-properties of the code and to inform later stages. Typically, this is what people
-mean when they talk about "Rust's type system". This includes the
-representation, inference, and checking of types, the trait system, and the
-borrow checker. These analyses do not happen as one big pass or set of
-contiguous passes. Rather, they are spread out throughout various parts of the
-compilation process and use different intermediate representations. For example,
+properties of the code and to inform later stages.
+Typically, this is what people mean when they talk about "Rust's type system".
+This includes the representation, inference, and checking of types, the trait system, and the
+borrow checker.
+These analyses do not happen as one big pass or set of contiguous passes.
+Rather, they are spread out throughout various parts of the
+compilation process and use different intermediate representations.
+For example,
type checking happens on the HIR, while borrow checking happens on the MIR.
Nonetheless, for the sake of presentation, we will discuss all of these
analyses in this part of the guide.
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 becaec831230c..dd802d71c0404 100644
--- a/src/doc/rustc-dev-guide/src/profiling/with-perf.md
+++ b/src/doc/rustc-dev-guide/src/profiling/with-perf.md
@@ -13,7 +13,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or
- Make a rustup toolchain pointing to that result
- see [the "build and run" section for instructions][b-a-r]
-[b-a-r]: ../building/how-to-build-and-run.html#toolchain
+[b-a-r]: ../building/how-to-build-and-run.md#toolchain
## Gathering a perf profile
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 28618cbb082a0..9893edd54b950 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
@@ -491,7 +491,7 @@ respect to incremental compilation:
`Crate` object available), and then retrieve it as any other crate.
Thus, function definitions for these queries do not exist.
-[mod]: ../query.html#adding-a-new-kind-of-query
+[mod]: ../query.md#adding-a-new-kind-of-query
## The projection query pattern
@@ -558,5 +558,5 @@ so including it in query result will increase the chance that the result won't b
See for more information.
-[query-model]: ./query-evaluation-model-in-detail.html
+[query-model]: ./query-evaluation-model-in-detail.md
[try_mark_green]: https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_middle/dep_graph/graph.rs.html
diff --git a/src/doc/rustc-dev-guide/src/query.md b/src/doc/rustc-dev-guide/src/query.md
index df0c21c9d719a..e58ea4e3e41e9 100644
--- a/src/doc/rustc-dev-guide/src/query.md
+++ b/src/doc/rustc-dev-guide/src/query.md
@@ -313,7 +313,7 @@ Let's go over these elements one by one:
query is processed (mostly with respect to [incremental compilation][incrcomp]).
[QueryKey]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/keys/trait.QueryKey.html
-[incrcomp]: queries/incremental-compilation-in-detail.html#query-modifiers
+[incrcomp]: queries/incremental-compilation-in-detail.md#query-modifiers
So, to add a query:
diff --git a/src/doc/rustc-dev-guide/src/solve/sharing-crates-with-rust-analyzer.md b/src/doc/rustc-dev-guide/src/solve/sharing-crates-with-rust-analyzer.md
index bf0d4fe3a11b7..f6be619bc1094 100644
--- a/src/doc/rustc-dev-guide/src/solve/sharing-crates-with-rust-analyzer.md
+++ b/src/doc/rustc-dev-guide/src/solve/sharing-crates-with-rust-analyzer.md
@@ -143,6 +143,124 @@ solver.
This infrastructure is used by the external fuzzing project:
.
+
+## Derived Traits
+
+- [`trait TypeVisitable` and `TypeVisitable_Generic`][type-visitable-trait-macro]
+- [`trait TypeFoldable` and `TypeFoldable_Generic`][type-foldable-trait-macro]
+- [`trait Lift` and `Lift_Generic`][lift-trait-macro]
+- [`trait GenericTypeVisitable`][generictypevisitable]
+
+These traits are used heavily in `rustc_type_ir`, their associated macros
+primarily exist to reduce the amount of boilerplate otherwise required to
+implement `Lift`, `TypeFoldable`, `TypeVisitable` and `GenericTypeVisitable`.
+
+### `trait TypeVisitable` and `TypeVisitable_Generic`
+[type-visitable-trait-macro]: #type-visitable-trait-macro
+
+This trait requires a struct or enum implements the method `visit_with(...)`,
+which in turn will transfer control to `TypeVisitor`, this can be
+[seen in detail here][rustc_typevisitable].
+
+While ostensibly similar due to their names, `TypeVisitable_Generic` and
+[`GenericTypeVisitable`][generictypevisitable] they implement two different
+visiting systems.
+
+- `TypeVisitable_Generic` means: derive the ordinary `TypeVisitable` trait
+ generically over an `Interner`.
+- `GenericTypeVisitable` means: derive the separate `GenericTypeVisitable` trait
+ used by non-nightly consumers such as rust-analyzer.
+
+#### `TypeVisitable_Generic`
+[typevisitable_generic]: #typevisitable_generic
+
+It visits the value's fields in declaration order, delegating each field to that
+field's own `TypeVisitable` implementation. The traversal can stop early if
+the visitor returns a residual result.
+
+Use `#[type_visitable(ignore)]` to ignore a field; it will not be part of the
+traversal and will not need to implement `TypeVisitable`. This should only
+be used when the field does not need to be traversed.
+
+### `trait TypeFoldable` and `TypeFoldable_Generic`
+[type-foldable-trait-macro]: #type-foldable-trait-macro
+
+The trait is implemented by things that need to embed types. This concept is
+discussed in detail [here](../ty-fold.md) and can be
+[followed in the source][rustc_typefoldable].
+
+`TypeFoldable_Generic` derives `rustc_type_ir::TypeFoldable` for a struct or
+enum.
+
+It consumes a value and reconstructs the same struct or enum variant after
+folding its fields. It generates both fallible and infallible folding methods.
+
+Use `#[type_foldable(identity)]` for a field whose value must be preserved
+unchanged. The macro moves that field directly into the reconstructed value
+instead of passing it to the folder. Its type therefore does not need to
+implement `TypeFoldable`.
+
+For an enum, the generated match contains one reconstruction arm per variant.
+
+### `trait Lift` and `Lift_Generic`
+[lift-trait-macro]: #lift-trait-macro
+
+The trait has a method `lift_to_interner(...)`. As the name suggests, it should
+'lift' something to the interner. [See here](../memory.md) to read more about
+the interner [and here for the source][rustc_lift].
+
+The macro `Lift_Generic` derives `Lift` for a struct or enum, with three
+non-obvious considerations:
+
+1. The generic parameters `I` and `J` are reserved for `I: Interner` and `J`
+ being the interner it is being lifted to.
+2. `PhantomData` is handled automatically, creating a new `PhantomData` but
+ _has_ to be included in the file through; `use std::marker::PhantomData;`
+ you cannot use `std::marker::PhantomData` directly on the field of a struct.
+3. The bounds are deliberately written as associated type bounds on the `Interner`
+ trait rather than as `where` clauses on `LiftInto`. Given only `I: LiftInto`,
+ Rust can then treat bounds such as the following as implied:
+
+```rust
+I::Ty: Lift
+I::Const: Lift
+```
+
+This allows `Lift_Generic` to emit the bound `I: LiftInto` while still
+calling `lift_to_interner` on fields of type `I::Ty`, `I::Const`, and the other
+declared associated types. It also guarantees that each call produces the
+destination field type expected after the derive rewrites `I::Assoc` to
+`J::Assoc`.
+
+Without `declare_lift_into!`, the derive would need to generate a separate bound
+for every interner-associated type used by every field. If a new `Interner`
+associated type is expected to work with `Lift_Generic`, it needs an appropriate
+`Lift` implementation and normally needs to be included in the
+`declare_lift_into!` invocation.
+
+If you want to ignore a field, such as a primitive like a `u32` which can't be
+lifted you can skip the field with `#[lift(ignore)]`.
+
+### `trait GenericTypeVisitable`
+[generictypevisitable]: #generictypevisitable
+
+This a separate more general traversal trait purely used by `rust-analyzer`.
+The visitor type is a parameter of the trait rather than a parameter of the
+method, and visiting neither returns a result nor supports short-circuiting.
+
+As such a struct or enum can derive both `TypeVisitable_Generic` and
+`GenericTypeVisitable`
+
+There is intentionally no ignore attribute. The traversal must visit every
+field. This is a soundness requirement for rust-analyzer's use of the traversal
+when tracing and garbage-collecting interned types.
+
+When the macro crate's `nightly` feature is enabled, the derive macro remains
+registered but emits no tokens. The `GenericTypeVisitable` trait and its
+traversal module are also excluded from the nightly configuration of
+`rustc_type_ir`; they exist only in its non-nightly configuration.
+
+
## Long-term plans for supporting rust-analyzer
In general, we aim to support rust-analyzer just as well as rustc in these shared crates—provided
@@ -189,4 +307,7 @@ There are still duplicated implementations between rustc and rust-analyzer—suc
[rustc oblctxt]: https://github.com/rust-lang/rust/blob/63b1db05801271e400954e41b8600a3cf1482363/compiler/rustc_trait_selection/src/traits/engine.rs#L48-L386
[r-a oblctxt]: https://github.com/rust-lang/rust-analyzer/blob/34f47d9298c478c12c6c4c0348771d1b05706e09/crates/hir-ty/src/next_solver/obligation_ctxt.rs
[rustc coerce]: https://github.com/rust-lang/rust/blob/63b1db05801271e400954e41b8600a3cf1482363/compiler/rustc_hir_typeck/src/coercion.rs
-[r-a coerce]: https://github.com/rust-lang/rust-analyzer/blob/34f47d9298c478c12c6c4c0348771d1b05706e09/crates/hir-ty/src/infer/coerce.rs
\ No newline at end of file
+[r-a coerce]: https://github.com/rust-lang/rust-analyzer/blob/34f47d9298c478c12c6c4c0348771d1b05706e09/crates/hir-ty/src/infer/coerce.rs
+[rustc_lift]: https://github.com/rust-lang/rust/blob/0913b18e489ac1011b580e31fa5559654be12bfc/compiler/rustc_type_ir/src/lift.rs#L18
+[rustc_typevisitable]: https://github.com/rust-lang/rust/blob/0913b18e489ac1011b580e31fa5559654be12bfc/compiler/rustc_type_ir/src/visit.rs#L62
+[rustc_typefoldable]: https://github.com/rust-lang/rust/blob/0913b18e489ac1011b580e31fa5559654be12bfc/compiler/rustc_type_ir/src/fold.rs#L71
\ No newline at end of file
diff --git a/src/doc/rustc-dev-guide/src/tests/compiletest.md b/src/doc/rustc-dev-guide/src/tests/compiletest.md
index 8e416c9a8be95..4573a04d0281c 100644
--- a/src/doc/rustc-dev-guide/src/tests/compiletest.md
+++ b/src/doc/rustc-dev-guide/src/tests/compiletest.md
@@ -216,9 +216,14 @@ A simple example of a test using `rustc_clean` is the [hello_world test].
### Debuginfo tests
-The tests in [`tests/debuginfo`] test debuginfo generation.
-They build a program, launch a debugger, and issue commands to the debugger.
-A single test can work with cdb, gdb, and lldb.
+>[!IMPORTANT]
+> As of [#159455](https://github.com/rust-lang/rust/pull/159455) These tests were made
+> opt-in. For further context, see:
+> [Stabilizing the state of the debuginfo test suite](https://github.com/rust-lang/compiler-team/issues/1012)
+
+The tests in [`tests/debuginfo`] test how debuginfo is interpreted by the supported debuggers, and
+confirm our visualizers still work as expected. They build a program, launch a debugger, and issue
+commands to the debugger. A single test can work with cdb, gdb, and lldb.
Most tests should have the `//@ compile-flags: -g` directive or something
similar to generate the appropriate debuginfo.
@@ -228,20 +233,16 @@ To set a breakpoint on a line, add a `// #break` comment on the line.
The debuginfo tests consist of a series of debugger commands along with
"check" lines which specify output that is expected from the debugger.
-The commands are comments of the form `// $DEBUGGER-command:$COMMAND` where
+The commands are comments of the form `//@ $DEBUGGER-command:$COMMAND` where
`$DEBUGGER` is the debugger being used and `$COMMAND` is the debugger command to execute.
The debugger values can be:
- `cdb`
- `gdb`
-- `gdbg` — GDB without Rust support (versions older than 7.11)
-- `gdbr` — GDB with Rust support
- `lldb`
-- `lldbg` — LLDB without Rust support
-- `lldbr` — LLDB with Rust support (this no longer exists)
-The command to check the output are of the form `// $DEBUGGER-check:$OUTPUT`
+The command to check the output are of the form `//@ $DEBUGGER-check:$OUTPUT`
where `$OUTPUT` is the output to expect.
For example, the following will build the test, start the debugger, set a
@@ -262,6 +263,35 @@ fn main() {
fn b() {}
```
+Additionally, there is a special command, `//@ $DEBUGGER-repr:$VAR_NAME` intended to verify
+variables (and their visualizers) with more granularity than can be achieved with simple string
+comparison. This directive should be preferred over the `-command`/`-check` whenever possible.
+
+> [!NOTE]
+> At time of writing (July 2026) this command is limited to LLDB, with an implementation coming soon
+> for GDB. There are not firm plans to port the logic to CDB.
+
+This command effectivly desugars into:
+
+```
+//@ $DEBUGGER-command:repr $VAR_NAME
+//@ $DEBUGGER-check:$VAR_NAME ok
+```
+
+The `repr $VAR_NAME` command is intercepted by special logic that uses the debuggers' API to inspect
+data that isn't reflected in the variable's printed output. The variable in memory is compared
+against input data stored in
+`tests/debuginfo//input/_input/.json` and
+provides detailed error messages on failure.
+
+> [!IMPORTANT]
+> `-repr` directives **are** compatible with the `--bless` option, unlike `-command`/`-check`.
+> `--bless`-ing a file with `-repr` commands will automatically create/update the appropriate
+> target's input data file.
+
+The implementation details of this command are further described in
+[the Testing section of the Debug Info chapter](../debuginfo/testing.md).
+
The following [directives](directives.md) are available to disable a test based on
the debugger currently being used:
@@ -272,7 +302,11 @@ the debugger currently being used:
to the given version
- `ignore-gdb-version: 7.11.90 - 8.0.9` — ignores the test if the version of
gdb is in a range (inclusive)
-- `min-lldb-version: 310` — ignores the test if the version of lldb is below the given version
+- `min-apple-lldb-version: 1703.0.236.21`/`min-llvm-lldb-version: 21.1.0` — ignores the test if the
+ version of lldb is below the given version.
+ Note: Apple's fork of LLDB (distributed with Xcode) uses a different versioning scheme that is not
+ easily mappable to LLVM's LLDB version numbers. As such, the version gates are specified by
+ vendor. Further info on manually checking version equivalence is available [here](../debuginfo/testing.md#lldb-versioning)
- `rust-lldb` — ignores the test if lldb is not contain the Rust plugin.
NOTE: The "Rust" version of LLDB doesn't exist anymore, so this will always be ignored.
This should probably be removed.
@@ -343,7 +377,7 @@ If you need to work with `#![no_std]` cross-compiling tests, consult the
### Assembly tests
The tests in [`tests/assembly-llvm`] test LLVM assembly output.
-They compile the test with the `--emit=asm` flag to emit a `.s` file with the assembly output.
+They compile the test with the `--emit asm` flag to emit a `.s` file with the assembly output.
They then run the LLVM [FileCheck] tool.
Each test should be annotated with the `//@ assembly-output:` directive with a
@@ -562,7 +596,7 @@ some reason, use the `//@ ignore-coverage-map` or `//@ ignore-coverage-run` dire
In `coverage-map` mode, these tests verify the mappings between source code
regions and coverage counters that are emitted by LLVM.
-They compile the test with `--emit=llvm-ir`, then use a custom tool ([`src/tools/coverage-dump`]) to
+They compile the test with `--emit llvm-ir`, then use a custom tool ([`src/tools/coverage-dump`]) to
extract and pretty-print the coverage mappings embedded in the IR.
These tests don't require the profiler runtime, so they run in PR CI jobs and are easy to
run/bless locally.
@@ -679,12 +713,11 @@ However, it uses the `--extern` flag
to link to the extern crate to make the crate be available as an extern prelude.
That allows you to specify the additional syntax of the `--extern` flag, such as
renaming a dependency.
-For example, `//@ aux-crate:foo=bar.rs` will compile
-`auxiliary/bar.rs` and make it available under then name `foo` within the test.
+For example, `//@ aux-crate: foo=bar.rs` will compile
+`auxiliary/bar.rs` and make it available under the name `foo` within the test.
This is similar to how Cargo does dependency renaming.
-It is also possible to
-specify [`--extern` modifiers](https://github.com/rust-lang/rust/issues/98405).
-For example, `//@ aux-crate:noprelude:foo=bar.rs`.
+It is also possible to specify [`--extern` modifiers].
+For example, `//@ aux-crate: noprelude:foo=bar.rs`.
`aux-bin` is similar to `aux-build` but will build a binary instead of a library.
The binary will be available in `auxiliary/bin` relative to the working directory of the test.
@@ -702,7 +735,7 @@ same parent folder as the main test file.
However, it also has four additional
preset behavior compared to `aux-build` for the proc-macro test auxiliary:
-1. The aux test file is built with `--crate-type=proc-macro`.
+1. The aux test file is built with `--crate-type proc-macro`.
2. The aux test file is built without `-C prefer-dynamic`, i.e. it will not try
to produce a dylib for the aux crate.
3. The aux crate is made available to the test file via extern prelude with
@@ -871,3 +904,5 @@ Where `N` is the number of threads to use for the parallel frontend, and `M` is
Also, when running with `--parallel-frontend-threads`, the `compare-output-by-lines` directive would be implied for all tests, since the output from the parallel frontend can be non-deterministic in terms of the order of lines.
The parallel frontend is available in UI tests only at the moment, and is not currently supported in other test suites.
+
+[`--extern` modifiers]: https://github.com/rust-lang/rust/issues/98405
diff --git a/src/doc/rustc-dev-guide/src/tests/directives.md b/src/doc/rustc-dev-guide/src/tests/directives.md
index 5468fff2b7775..cca649fbfdd40 100644
--- a/src/doc/rustc-dev-guide/src/tests/directives.md
+++ b/src/doc/rustc-dev-guide/src/tests/directives.md
@@ -51,7 +51,7 @@ Directives can generally be found by browsing the
### Auxiliary builds
-See [Building auxiliary crates](compiletest.html#building-auxiliary-crates)
+See [Building auxiliary crates](compiletest.md#building-auxiliary-crates)
| Directive | Explanation | Supported test suites | Possible values |
|-----------------------|-------------------------------------------------------------------------------------------------------|----------------------------------------|--------------------------------------------------------------------|
@@ -62,7 +62,7 @@ See [Building auxiliary crates](compiletest.html#building-auxiliary-crates)
| `proc-macro` | Similar to `aux-build`, but for aux forces host and don't use `-Cprefer-dynamic`[^pm]. | All except `run-make`/`run-make-cargo` | Path to auxiliary proc-macro `.rs` file |
| `build-aux-docs` | Build docs for auxiliaries as well. Note that this only works with `aux-build`, not `aux-crate`. | All except `run-make`/`run-make-cargo` | N/A |
-[^pm]: please see the [Auxiliary proc-macro section](compiletest.html#auxiliary-proc-macro) in the compiletest chapter for specifics.
+[^pm]: please see the [Auxiliary proc-macro section](compiletest.md#auxiliary-proc-macro) in the compiletest chapter for specifics.
### Controlling outcome expectations
@@ -309,7 +309,7 @@ separate tools.
For more information, please read their respective chapters as linked above.
[rustdoc-html-tests]: ../rustdoc-internals/rustdoc-html-test-suite.md
-[rustdoc-js-tests]: ../rustdoc-internals/search.html#testing-the-search-engine
+[rustdoc-js-tests]: ../rustdoc-internals/search.md#testing-the-search-engine
[rustdoc-json-tests]: ../rustdoc-internals/rustdoc-json-test-suite.md
### Pretty printing
diff --git a/src/doc/rustc-dev-guide/src/tests/x86_64-gnu-parallel-frontend.md b/src/doc/rustc-dev-guide/src/tests/optional-x86_64-gnu-parallel-frontend.md
similarity index 92%
rename from src/doc/rustc-dev-guide/src/tests/x86_64-gnu-parallel-frontend.md
rename to src/doc/rustc-dev-guide/src/tests/optional-x86_64-gnu-parallel-frontend.md
index e8c91044be1d7..20dc5adeaa484 100644
--- a/src/doc/rustc-dev-guide/src/tests/x86_64-gnu-parallel-frontend.md
+++ b/src/doc/rustc-dev-guide/src/tests/optional-x86_64-gnu-parallel-frontend.md
@@ -1,5 +1,7 @@
# Parallel frontend testing on CI
+NOTE: this job is optional and allowed to fail.
+
If you see any test failures in `tests/ui` from the CI job `x86_64-gnu-parallel-frontend`, please
add `//@ ignore-parallel-frontend triage` to the failing test, even if your PR is otherwise
entirely unrelated to parallel compiler or its testing.
diff --git a/src/doc/rustc-dev-guide/src/traits/caching.md b/src/doc/rustc-dev-guide/src/traits/caching.md
index be72f6e89f9ac..6c3f94d96e3fd 100644
--- a/src/doc/rustc-dev-guide/src/traits/caching.md
+++ b/src/doc/rustc-dev-guide/src/traits/caching.md
@@ -24,7 +24,7 @@ On the other hand, if there is no hit, we need to go through the [selection
process] from scratch. Suppose, we come to the conclusion that the only
possible impl is this one, with def-id 22:
-[selection process]: ./resolution.html#selection
+[selection process]: ./resolution.md#selection
```rust,ignore
impl Foo for usize { ... } // Impl #22
@@ -34,7 +34,7 @@ We would then record in the cache `usize : Foo<$0> => ImplCandidate(22)`. Next
we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify
`$t` with `isize`.
-[confirm]: ./resolution.html#confirmation
+[confirm]: ./resolution.md#confirmation
Now, at some later time, we might come along and see a `usize :
Foo<$u>`. When replaced with a placeholder, this would yield `usize : Foo<$0>`, just as
@@ -61,7 +61,7 @@ to be pretty clearly safe and also still retains a very high hit rate
**TODO**: it looks like `pick_candidate_cache` no longer exists. In
general, is this section still accurate at all?
-[`ParamEnv`]: ../typing-parameter-envs.html
-[`tcx`]: ../ty.html
+[`ParamEnv`]: ../typing-parameter-envs.md
+[`tcx`]: ../ty.md
[#18290]: https://github.com/rust-lang/rust/issues/18290
[#22019]: https://github.com/rust-lang/rust/issues/22019
diff --git a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md
index 389f380e4b8de..06b41e27c644a 100644
--- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md
+++ b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md
@@ -3,7 +3,7 @@
The "start" of the trait system is the **canonical query** (these are
both queries in the more general sense of the word – something you
would like to know the answer to – and in the
-[rustc-specific sense](../query.html)). The idea is that the type
+[rustc-specific sense](../query.md)). The idea is that the type
checker or other parts of the system, may in the course of doing their
thing want to know whether some trait is implemented for some type
(e.g., is `u32: Debug` true?). Or they may want to
@@ -244,4 +244,3 @@ don't know what that type is yet!).
error at this point, since the element types of `t` and `u` are still
not yet known, even though they are known to be the same.)
-
diff --git a/src/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md
index 616636d616647..4bd56a020f14f 100644
--- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md
+++ b/src/doc/rustc-dev-guide/src/traits/canonicalization.md
@@ -1,7 +1,7 @@
# Canonicalization
> **NOTE**: FIXME: The content of this chapter has some overlap with
-> [Next-gen trait solving Canonicalization chapter](../solve/canonicalization.html).
+> [Next-gen trait solving Canonicalization chapter](../solve/canonicalization.md).
> It is suggested to reorganize these contents in the future.
Canonicalization is the process of **isolating** an inference value
@@ -10,7 +10,7 @@ from its context. It is a key part of implementing
to get more context.
Canonicalization is really based on a very simple concept: every
-[inference variable](../type-inference.html#vars) is always in one of
+[inference variable](../type-inference.md#vars) is always in one of
two states: either it is **unbound**, in which case we don't know yet
what type it is, or it is **bound**, in which case we do. So to
isolate some data-structure T that contains types/regions from its
@@ -20,7 +20,7 @@ starting from zero and numbered in a fixed order (left to right, for
the most part, but really it doesn't matter as long as it is
consistent).
-[cq]: ./canonical-queries.html
+[cq]: ./canonical-queries.md
So, for example, if we have the type `X = (?T, ?U)`, where `?T` and
`?U` are distinct, unbound inference variables, then the canonical
@@ -45,7 +45,7 @@ trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound.
This query contains two unbound variables, but it also contains the
lifetime `'static`. The trait system generally ignores all lifetimes
and treats them equally, so when canonicalizing, we will *also*
-replace any [free lifetime](../appendix/background.html#free-vs-bound) with a
+replace any [free lifetime](../appendix/background.md#free-vs-bound) with a
canonical variable (Note that `'static` is actually a _free_ lifetime
variable here. We are not considering it in the typing context of the whole
program but only in the context of this trait reference. Mathematically, we
@@ -111,7 +111,7 @@ suffice to say that it will compute a [certainty value][cqqr] (`Proven` or
`Ambiguous`) and have side-effects on the inference variables we've
created. For example, if there were only one impl of `Foo`, like so:
-[cqqr]: ./canonical-queries.html#query-response
+[cqqr]: ./canonical-queries.md#query-response
```rust,ignore
impl<'a, X> Foo<'a, X> for Vec
@@ -257,4 +257,3 @@ cases where the value is just a canonical variable. In our example,
`values[2]` is `?C`, so that means we can deduce that `?C := ?B` and
`'?D := 'static`. This gives us a partial set of values. Anything for
which we do not find a value, we create an inference variable.)
-
diff --git a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md
index 9dbb62a7e3af8..ffab13374c9cc 100644
--- a/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md
+++ b/src/doc/rustc-dev-guide/src/traits/goals-and-clauses.md
@@ -2,7 +2,7 @@
In logic programming terms, a **goal** is something that you must
prove and a **clause** is something that you know is true. As
-described in the [lowering to logic](./lowering-to-logic.html)
+described in the [lowering to logic](./lowering-to-logic.md)
chapter, Rust's trait solver is based on an extension of hereditary
harrop (HH) clauses, which extend traditional Prolog Horn clauses with
a few new superpowers.
diff --git a/src/doc/rustc-dev-guide/src/traits/hrtb.md b/src/doc/rustc-dev-guide/src/traits/hrtb.md
index aa85448afea5c..1d671e3ebcf71 100644
--- a/src/doc/rustc-dev-guide/src/traits/hrtb.md
+++ b/src/doc/rustc-dev-guide/src/traits/hrtb.md
@@ -41,7 +41,7 @@ subtyping, we recommend you read the paper). There are a few parts:
3. Check for _placeholder leaks_.
[hrsubtype]: ./hrtb.md
-[placeholder]: ../appendix/glossary.html#placeholder
+[placeholder]: ../appendix/glossary.md#placeholder
[paper by SPJ]: https://www.microsoft.com/en-us/research/publication/practical-type-inference-for-arbitrary-rank-types
So let's work through our example.
diff --git a/src/doc/rustc-dev-guide/src/traits/resolution.md b/src/doc/rustc-dev-guide/src/traits/resolution.md
index f668d6ccf6198..394d800b5f868 100644
--- a/src/doc/rustc-dev-guide/src/traits/resolution.md
+++ b/src/doc/rustc-dev-guide/src/traits/resolution.md
@@ -6,7 +6,7 @@ some non-obvious things.
**Note:** This chapter (and its subchapters) describe how the trait
solver **currently** works. However, we are in the process of
designing a new trait solver. If you'd prefer to read about *that*,
-see [*this* subchapter](./chalk.html).
+see [*this* subchapter](./chalk.md).
## Major concepts
@@ -181,7 +181,7 @@ in that list. If so, it is considered satisfied. More precisely, we
want to check whether there is a where-clause obligation that is for
the same trait (or some subtrait) and which can match against the obligation.
-[parameter environment]: ../typing-parameter-envs.html
+[parameter environment]: ../typing-parameter-envs.md
Consider this simple example:
diff --git a/src/doc/rustc-dev-guide/src/type-inference.md b/src/doc/rustc-dev-guide/src/type-inference.md
index 24982a209fd0d..196fcdd9190c3 100644
--- a/src/doc/rustc-dev-guide/src/type-inference.md
+++ b/src/doc/rustc-dev-guide/src/type-inference.md
@@ -116,7 +116,7 @@ actual return type is not `()`, but rather `InferOk<()>`. The
to ensure that these are fulfilled (typically by enrolling them in a
fulfillment context). See the [trait chapter] for more background on that.
-[trait chapter]: traits/resolution.html
+[trait chapter]: traits/resolution.md
You can similarly enforce subtyping through `infcx.at(..).sub(..)`. The same
basic concepts as above apply.
diff --git a/src/doc/rustc-dev-guide/src/variance.md b/src/doc/rustc-dev-guide/src/variance.md
index 96fde1d87cca5..de259d38c3ec0 100644
--- a/src/doc/rustc-dev-guide/src/variance.md
+++ b/src/doc/rustc-dev-guide/src/variance.md
@@ -2,7 +2,7 @@
For a more general background on variance, see the [background] appendix.
-[background]: ./appendix/background.html
+[background]: ./appendix/background.md
During type checking, we must infer the variance of type and lifetime parameters.
The algorithm is taken from Section 4 of the paper ["Taming the
@@ -139,7 +139,7 @@ crate (through `crate_variances`), but since most changes will not result in a
change to the actual results from variance inference, the `variances_of` query
will wind up being considered green after it is re-evaluated.
-[rga]: ./queries/incremental-compilation.html
+[rga]: ./queries/incremental-compilation.md
diff --git a/src/doc/rustc-dev-guide/src/walkthrough.md b/src/doc/rustc-dev-guide/src/walkthrough.md
index 212fb298fd0b3..b7eb2b56617bc 100644
--- a/src/doc/rustc-dev-guide/src/walkthrough.md
+++ b/src/doc/rustc-dev-guide/src/walkthrough.md
@@ -244,7 +244,7 @@ There are a couple of things that may happen for some PRs during the review proc
some merge conflicts with other PRs that happen to get merged first.
You should fix these merge conflicts using the normal git procedures.
-[crater]: ./tests/crater.html
+[crater]: ./tests/crater.md
If you are not doing a new feature or something like that (e.g. if you are
fixing a bug), then that's it!