Skip to content

Commit c1db850

Browse files
committedJun 14, 2025
Merge ref 'd087f112b7d1:/library/compiler-builtins' from https://github.com/rust-lang/rust
Pull recent changes from rust-lang/rust via Josh. Upstream ref: d087f112b7d1323446c7b39a8b616aee7fa56b3d Filtered ref: 2d43ce8ac022170e5383f7e5a188b55564b6566a
2 parents ec32bcf + 89ebba9 commit c1db850

24 files changed

+274
-289
lines changed
 

‎rust-version

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
99e7c15e81385b38a8186b51edc4577d5d7b5bdd
1+
14346303d760027e53214e705109a62c0f00b214

‎src/SUMMARY.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -63,10 +63,8 @@
6363
- [Notification groups](notification-groups/about.md)
6464
- [Apple](notification-groups/apple.md)
6565
- [ARM](notification-groups/arm.md)
66-
- [Cleanup Crew](notification-groups/cleanup-crew.md)
6766
- [Emscripten](notification-groups/emscripten.md)
6867
- [Fuchsia](notification-groups/fuchsia.md)
69-
- [LLVM](notification-groups/llvm.md)
7068
- [RISC-V](notification-groups/risc-v.md)
7169
- [Rust for Linux](notification-groups/rust-for-linux.md)
7270
- [WASI](notification-groups/wasi.md)
@@ -101,6 +99,8 @@
10199
- [Rustdoc internals](./rustdoc-internals.md)
102100
- [Search](./rustdoc-internals/search.md)
103101
- [The `rustdoc` test suite](./rustdoc-internals/rustdoc-test-suite.md)
102+
- [The `rustdoc-gui` test suite](./rustdoc-internals/rustdoc-gui-test-suite.md)
103+
- [The `rustdoc-json` test suite](./rustdoc-internals/rustdoc-json-test-suite.md)
104104
- [Autodiff internals](./autodiff/internals.md)
105105
- [Installation](./autodiff/installation.md)
106106
- [How to debug](./autodiff/debugging.md)

‎src/autodiff/flags.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,9 @@ LooseTypes // Risk incorrect derivatives instead of aborting when missing Type I
1616
```
1717

1818
<div class="warning">
19+
1920
`LooseTypes` is often helpful to get rid of Enzyme errors stating `Can not deduce type of <X>` and to be able to run some code. But please keep in mind that this flag absolutely has the chance to cause incorrect gradients. Even worse, the gradients might be correct for certain input values, but not for others. So please create issues about such bugs and only use this flag temporarily while you wait for your bug to be fixed.
21+
2022
</div>
2123

2224
### Benchmark flags

‎src/building/bootstrapping/debugging-bootstrap.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ Bootstrap will conditionally build `tracing` support and enable `tracing` output
5555

5656
Example basic usage[^just-trace]:
5757

58-
[^just-trace]: It is not recommend to use *just* `BOOTSTRAP_TRACING=TRACE` because that will dump *everything* at `TRACE` level, including logs intentionally gated behind custom targets as they are too verbose even for `TRACE` level by default.
58+
[^just-trace]: It is not recommended to use *just* `BOOTSTRAP_TRACING=TRACE` because that will dump *everything* at `TRACE` level, including logs intentionally gated behind custom targets as they are too verbose even for `TRACE` level by default.
5959

6060
```bash
6161
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x build library --stage 1

‎src/building/suggested.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -59,6 +59,14 @@ always overrides the inner ones.
5959

6060
## Configuring `rust-analyzer` for `rustc`
6161

62+
### Checking the "library" tree
63+
64+
Checking the "library" tree requires a stage1 compiler, which can be a heavy process on some computers.
65+
For this reason, bootstrap has a flag called `--skip-std-check-if-no-download-rustc` that skips checking the
66+
"library" tree if `rust.download-rustc` isn't available. If you want to avoid putting a heavy load on your computer
67+
with `rust-analyzer`, you can add the `--skip-std-check-if-no-download-rustc` flag to your `./x check` command in
68+
the `rust-analyzer` configuration.
69+
6270
### Project-local rust-analyzer setup
6371

6472
`rust-analyzer` can help you check and format your code whenever you save a

‎src/coroutine-closures.md

Lines changed: 17 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,22 @@
1+
# Async closures/"coroutine-closures"
2+
3+
<!-- toc -->
4+
15
Please read [RFC 3668](https://rust-lang.github.io/rfcs/3668-async-closures.html) to understand the general motivation of the feature. This is a very technical and somewhat "vertical" chapter; ideally we'd split this and sprinkle it across all the relevant chapters, but for the purposes of understanding async closures *holistically*, I've put this together all here in one chapter.
26

3-
# Coroutine-closures -- a technical deep dive
7+
## Coroutine-closures -- a technical deep dive
48

59
Coroutine-closures are a generalization of async closures, being special syntax for closure expressions which return a coroutine, notably one that is allowed to capture from the closure's upvars.
610

711
For now, the only usable kind of coroutine-closure is the async closure, and supporting async closures is the extent of this PR. We may eventually support `gen || {}`, etc., and most of the problems and curiosities described in this document apply to all coroutine-closures in general.
812

913
As a consequence of the code being somewhat general, this document may flip between calling them "async closures" and "coroutine-closures". The future that is returned by the async closure will generally be called the "coroutine" or the "child coroutine".
1014

11-
## HIR
15+
### HIR
1216

13-
Async closures (and in the future, other coroutine flavors such as `gen`) are represented in HIR as a `hir::Closure` whose closure-kind is `ClosureKind::CoroutineClosure(_)`[^k1], which wraps an async block, which is also represented in HIR as a `hir::Closure`) and whose closure-kind is `ClosureKind::Closure(CoroutineKind::Desugared(_, CoroutineSource::Closure))`[^k2].
17+
Async closures (and in the future, other coroutine flavors such as `gen`) are represented in HIR as a `hir::Closure`.
18+
The closure-kind of the `hir::Closure` is `ClosureKind::CoroutineClosure(_)`[^k1], which wraps an async block, which is also represented in HIR as a `hir::Closure`.
19+
The closure-kind of the async block is `ClosureKind::Closure(CoroutineKind::Desugared(_, CoroutineSource::Closure))`[^k2].
1420

1521
[^k1]: <https://github.com/rust-lang/rust/blob/5ca0e9fa9b2f92b463a0a2b0b34315e09c0b7236/compiler/rustc_ast_lowering/src/expr.rs#L1147>
1622

@@ -24,7 +30,7 @@ Like `async fn`, when lowering an async closure's body, we need to unconditional
2430

2531
[^l3]: <https://github.com/rust-lang/rust/blob/5ca0e9fa9b2f92b463a0a2b0b34315e09c0b7236/compiler/rustc_hir_typeck/src/upvar.rs#L250-L256>
2632

27-
## `rustc_middle::ty` Representation
33+
### `rustc_middle::ty` Representation
2834

2935
For the purposes of keeping the implementation mostly future-compatible (i.e. with gen `|| {}` and `async gen || {}`), most of this section calls async closures "coroutine-closures".
3036

@@ -72,7 +78,7 @@ To most easily construct the `Coroutine` that a coroutine-closure returns, you c
7278

7379
Most of the args to that function will be components that you can get out of the `CoroutineArgs`, except for the `goal_kind: ClosureKind` which controls which flavor of coroutine to return based off of the `ClosureKind` passed in -- i.e. it will prepare the by-ref coroutine if `ClosureKind::Fn | ClosureKind::FnMut`, and the by-move coroutine if `ClosureKind::FnOnce`.
7480

75-
## Trait Hierarchy
81+
### Trait Hierarchy
7682

7783
We introduce a parallel hierarchy of `Fn*` traits that are implemented for . The motivation for the introduction was covered in a blog post: [Async Closures](https://hackmd.io/@compiler-errors/async-closures).
7884

@@ -98,11 +104,11 @@ We mention above that "regular" callable types can implement `AsyncFn*`, but the
98104

99105
See the "follow-up: when do..." section below for an elaborated answer. The full answer describes a pretty interesting and hopefully thorough heuristic that is used to ensure that most async closures "just work".
100106

101-
## Tale of two bodies...
107+
### Tale of two bodies...
102108

103109
When async closures are called with `AsyncFn`/`AsyncFnMut`, they return a coroutine that borrows from the closure. However, when they are called via `AsyncFnOnce`, we consume that closure, and cannot return a coroutine that borrows from data that is now dropped.
104110

105-
To work around around this limitation, we synthesize a separate by-move MIR body for calling `AsyncFnOnce::call_once` on a coroutine-closure that can be called by-ref.
111+
To work around this limitation, we synthesize a separate by-move MIR body for calling `AsyncFnOnce::call_once` on a coroutine-closure that can be called by-ref.
106112

107113
This body operates identically to the "normal" coroutine returned from calling the coroutine-closure, except for the fact that it has a different set of upvars, since we must *move* the captures from the parent coroutine-closure into the child coroutine.
108114

@@ -120,7 +126,7 @@ Since we've synthesized a new def id, this query is also responsible for feeding
120126

121127
[^b3]: <https://github.com/rust-lang/rust/blob/5ca0e9fa9b2f92b463a0a2b0b34315e09c0b7236/compiler/rustc_mir_transform/src/lib.rs#L339-L342>
122128

123-
## Closure signature inference
129+
### Closure signature inference
124130

125131
The closure signature inference algorithm for async closures is a bit more complicated than the inference algorithm for "traditional" closures. Like closures, we iterate through all of the clauses that may be relevant (for the expectation type passed in)[^deduce1].
126132

@@ -173,7 +179,7 @@ s.as_bytes();
173179

174180
So *instead*, we use this alias (in this case, a projection: `AsyncFnKindHelper::Upvars<'env, ...>`) to delay the computation of the *tupled upvars* and give us something to put in its place, while still allowing us to return a `TyKind::Coroutine` (which is a rigid type) and we may successfully confirm the built-in traits we need (in our case, `Future`), since the `Future` implementation doesn't depend on the upvars at all.
175181

176-
## Upvar analysis
182+
### Upvar analysis
177183

178184
By and large, the upvar analysis for coroutine-closures and their child coroutines proceeds like normal upvar analysis. However, there are several interesting bits that happen to account for async closures' special natures:
179185

@@ -262,7 +268,7 @@ let c = async || {
262268

263269
If either of these cases apply, then we should capture the borrow with the lifetime of the parent coroutine-closure's env. Luckily, if this function is not correct, then the program is not unsound, since we still borrowck and validate the choices made from this function -- the only side-effect is that the user may receive unnecessary borrowck errors.
264270

265-
## Instance resolution
271+
### Instance resolution
266272

267273
If a coroutine-closure has a closure-kind of `FnOnce`, then its `AsyncFnOnce::call_once` and `FnOnce::call_once` implementations resolve to the coroutine-closure's body[^res1], and the `Future::poll` of the coroutine that gets returned resolves to the body of the child closure.
268274

@@ -282,7 +288,7 @@ This is represented by the `ConstructCoroutineInClosureShim`[^i1]. The `receiver
282288

283289
[^i3]: <https://github.com/rust-lang/rust/blob/07cbbdd69363da97075650e9be24b78af0bcdd23/compiler/rustc_middle/src/ty/instance.rs#L841>
284290

285-
## Borrow-checking
291+
### Borrow-checking
286292

287293
It turns out that borrow-checking async closures is pretty straightforward. After adding a new `DefiningTy::CoroutineClosure`[^bck1] variant, and teaching borrowck how to generate the signature of the coroutine-closure[^bck2], borrowck proceeds totally fine.
288294

‎src/getting-started.md

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -158,9 +158,6 @@ feel comfortable jumping straight into the large `rust-lang/rust` codebase.
158158
The following tasks are doable without much background knowledge but are
159159
incredibly helpful:
160160

161-
- [Cleanup crew][iceb]: find minimal reproductions of ICEs, bisect
162-
regressions, etc. This is a way of helping that saves a ton of time for
163-
others to fix an error later.
164161
- [Writing documentation][wd]: if you are feeling a bit more intrepid, you could try
165162
to read a part of the code and write doc comments for it. This will help you
166163
to learn some part of the compiler while also producing a useful artifact!
@@ -179,7 +176,6 @@ incredibly helpful:
179176
[users]: https://users.rust-lang.org/
180177
[so]: http://stackoverflow.com/questions/tagged/rust
181178
[community-library]: https://github.com/rust-lang/rfcs/labels/A-community-library
182-
[iceb]: ./notification-groups/cleanup-crew.md
183179
[wd]: ./contributing.md#writing-documentation
184180
[wg]: https://rust-lang.github.io/compiler-team/working-groups/
185181
[triage]: ./contributing.md#issue-triage

‎src/git.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -142,7 +142,8 @@ The most common cause is that you rebased after a change and ran `git add .` wit
142142
`x` to update the submodules. Alternatively, you might have run `cargo fmt` instead of `x fmt`
143143
and modified files in a submodule, then committed the changes.
144144

145-
To fix it, do the following things:
145+
To fix it, do the following things (if you changed a submodule other than cargo,
146+
replace `src/tools/cargo` with the path to that submodule):
146147

147148
1. See which commit has the accidental changes: `git log --stat -n1 src/tools/cargo`
148149
2. Revert the changes to that commit: `git checkout <my-commit>~ src/tools/cargo`. Type `~`

‎src/normalization.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -265,13 +265,13 @@ Another problem was that it was not possible to normalize `ParamEnv`s correctly
265265

266266
Given a type such as `for<'a> fn(<?x as Trait<'a>::Assoc>)`, it is not possible to correctly handle this with the old solver's approach to normalization.
267267

268-
If we were to normalize it to `for<'a> fn(?y)` and register a goal to normalize `for<'a> <?x as Trait<'a>>::Assoc -> ?y`, this would result in errors in cases where `<?x as Trait<'a>>::Assoc` normalized to `&'a u32`. The inference variable `?y` would be in a lower [universe][universes] than the placeholders made when instantiating the `for<'a>` binder.
268+
If we were to normalize it to `for<'a> fn(?y)` and register a goal to normalize `for<'a> <?x as Trait<'a>>::Assoc -> ?y`, this would result in errors in cases where `<?x as Trait<'a>>::Assoc` normalized to `&'a u32`. The inference variable `?y` would be in a lower [universe] than the placeholders made when instantiating the `for<'a>` binder.
269269

270270
Leaving the alias unnormalized would also be wrong as the old solver expects all aliases to be rigid. This was a soundness bug before the new solver was stabilized in coherence: [relating projection substs is unsound during coherence](https://github.com/rust-lang/rust/issues/102048).
271271

272272
Ultimately this means that it is not always possible to ensure all aliases inside of a value are rigid.
273273

274-
[universes]: https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/placeholders_and_universes.html#what-is-a-universe
274+
[universe]: borrow_check/region_inference/placeholders_and_universes.md#what-is-a-universe
275275
[deeply_normalize]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/normalize/trait.NormalizeExt.html#tymethod.deeply_normalize
276276

277277
## Handling uses of diverging aliases

‎src/notification-groups/about.md

Lines changed: 4 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -21,9 +21,7 @@ search for existing issues that haven't been claimed yet.
2121
Here's the list of the notification groups:
2222
- [Apple](./apple.md)
2323
- [ARM](./arm.md)
24-
- [Cleanup Crew](./cleanup-crew.md)
2524
- [Emscripten](./emscripten.md)
26-
- [LLVM Icebreakers](./llvm.md)
2725
- [RISC-V](./risc-v.md)
2826
- [WASI](./wasi.md)
2927
- [WebAssembly](./wasm.md)
@@ -64,9 +62,7 @@ Example PRs:
6462

6563
* [Example of adding yourself to the Apple group.](https://github.com/rust-lang/team/pull/1434)
6664
* [Example of adding yourself to the ARM group.](https://github.com/rust-lang/team/pull/358)
67-
* [Example of adding yourself to the Cleanup Crew.](https://github.com/rust-lang/team/pull/221)
6865
* [Example of adding yourself to the Emscripten group.](https://github.com/rust-lang/team/pull/1579)
69-
* [Example of adding yourself to the LLVM group.](https://github.com/rust-lang/team/pull/140)
7066
* [Example of adding yourself to the RISC-V group.](https://github.com/rust-lang/team/pull/394)
7167
* [Example of adding yourself to the WASI group.](https://github.com/rust-lang/team/pull/1580)
7268
* [Example of adding yourself to the WebAssembly group.](https://github.com/rust-lang/team/pull/1581)
@@ -81,9 +77,7 @@ group. For example:
8177
```text
8278
@rustbot ping apple
8379
@rustbot ping arm
84-
@rustbot ping cleanup-crew
8580
@rustbot ping emscripten
86-
@rustbot ping icebreakers-llvm
8781
@rustbot ping risc-v
8882
@rustbot ping wasi
8983
@rustbot ping wasm
@@ -92,12 +86,12 @@ group. For example:
9286

9387
To make some commands shorter and easier to remember, there are aliases,
9488
defined in the [`triagebot.toml`] file. For example, all of these commands
95-
are equivalent and will ping the Cleanup Crew:
89+
are equivalent and will ping the Apple group:
9690

9791
```text
98-
@rustbot ping cleanup
99-
@rustbot ping bisect
100-
@rustbot ping reduce
92+
@rustbot ping apple
93+
@rustbot ping macos
94+
@rustbot ping ios
10195
```
10296

10397
Keep in mind that these aliases are meant to make humans' life easier.

‎src/notification-groups/cleanup-crew.md

Lines changed: 0 additions & 90 deletions
This file was deleted.

‎src/notification-groups/llvm.md

Lines changed: 0 additions & 38 deletions
This file was deleted.

‎src/rustdoc-internals.md

Lines changed: 0 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -270,35 +270,6 @@ in `test.rs` is the function `make_test`, which is where hand-written
270270
Some extra reading about `make_test` can be found
271271
[here](https://quietmisdreavus.net/code/2018/02/23/how-the-doctests-get-made/).
272272

273-
## Dotting i's And Crossing t's
274-
275-
So that's `rustdoc`'s code in a nutshell, but there's more things in the
276-
compiler that deal with it. Since we have the full `compiletest` suite at hand,
277-
there's a set of tests in `tests/rustdoc` that make sure the final `HTML` is
278-
what we expect in various situations. These tests also use a supplementary
279-
script, `src/etc/htmldocck.py`, that allows it to look through the final `HTML`
280-
using `XPath` notation to get a precise look at the output. The full
281-
description of all the commands available to `rustdoc` tests (e.g. [`@has`] and
282-
[`@matches`]) is in [`htmldocck.py`].
283-
284-
To use multiple crates in a `rustdoc` test, add `//@ aux-build:filename.rs`
285-
to the top of the test file. `filename.rs` should be placed in an `auxiliary`
286-
directory relative to the test file with the comment. If you need to build
287-
docs for the auxiliary file, use `//@ build-aux-docs`.
288-
289-
In addition, there are separate tests for the search index and `rustdoc`'s
290-
ability to query it. The files in `tests/rustdoc-js` each contain a
291-
different search query and the expected results, broken out by search tab.
292-
These files are processed by a script in `src/tools/rustdoc-js` and the `Node.js`
293-
runtime. These tests don't have as thorough of a writeup, but a broad example
294-
that features results in all tabs can be found in `basic.js`. The basic idea is
295-
that you match a given `QUERY` with a set of `EXPECTED` results, complete with
296-
the full item path of each item.
297-
298-
[`@has`]: https://github.com/rust-lang/rust/blob/master/src/etc/htmldocck.py#L39
299-
[`@matches`]: https://github.com/rust-lang/rust/blob/master/src/etc/htmldocck.py#L44
300-
[`htmldocck.py`]: https://github.com/rust-lang/rust/blob/master/src/etc/htmldocck.py
301-
302273
## Testing Locally
303274

304275
Some features of the generated `HTML` documentation might require local
Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
# The `rustdoc-gui` test suite
2+
3+
> **FIXME**: This section is a stub. Please help us flesh it out!
4+
5+
This page is about the test suite named `rustdoc-gui` used to test the "GUI" of `rustdoc` (i.e., the HTML/JS/CSS as rendered in a browser).
6+
For other rustdoc-specific test suites, see [Rustdoc test suites].
7+
8+
These use a NodeJS-based tool called [`browser-UI-test`] that uses [puppeteer] to run tests in a headless browser and check rendering and interactivity. For information on how to write this form of test, see [`tests/rustdoc-gui/README.md`][rustdoc-gui-readme] as well as [the description of the `.goml` format][goml-script]
9+
10+
[Rustdoc test suites]: ../tests/compiletest.md#rustdoc-test-suites
11+
[`browser-UI-test`]: https://github.com/GuillaumeGomez/browser-UI-test/
12+
[puppeteer]: https://pptr.dev/
13+
[rustdoc-gui-readme]: https://github.com/rust-lang/rust/blob/master/tests/rustdoc-gui/README.md
14+
[goml-script]: https://github.com/GuillaumeGomez/browser-UI-test/blob/master/goml-script.md
Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
# The `rustdoc-json` test suite
2+
3+
> **FIXME**: This section is a stub. It will be populated by [PR #2422](https://github.com/rust-lang/rustc-dev-guide/pull/2422/).
Lines changed: 135 additions & 56 deletions
Original file line numberDiff line numberDiff line change
@@ -1,112 +1,191 @@
11
# The `rustdoc` test suite
22

3-
This page is specifically about the test suite named `rustdoc`.
4-
For other test suites used for testing rustdoc, see [Rustdoc tests](../rustdoc.md#tests).
3+
This page is about the test suite named `rustdoc` used to test the HTML output of `rustdoc`.
4+
For other rustdoc-specific test suites, see [Rustdoc test suites].
55

6-
The `rustdoc` test suite is specifically used to test the HTML output of rustdoc.
6+
Each test file in this test suite is simply a Rust source file `file.rs` sprinkled with
7+
so-called *directives* located inside normal Rust code comments.
8+
These come in two flavors: *Compiletest* and *HtmlDocCk*.
79

8-
This is achieved by means of `htmldocck.py`, a custom checker script that leverages [XPath].
10+
To learn more about the former, read [Compiletest directives].
11+
For the latter, continue reading.
912

10-
[XPath]: https://en.wikipedia.org/wiki/XPath
13+
Internally, [`compiletest`] invokes the supplementary checker script [`htmldocck.py`].
1114

12-
## Directives
13-
Directives to htmldocck are similar to those given to `compiletest` in that they take the form of `//@` comments.
15+
[Rustdoc test suites]: ../tests/compiletest.md#rustdoc-test-suites
16+
[`compiletest`]: ../tests/compiletest.md
17+
[`htmldocck.py`]: https://github.com/rust-lang/rust/blob/master/src/etc/htmldocck.py
1418

15-
In addition to the directives listed here,
16-
`rustdoc` tests also support most
17-
[compiletest directives](../tests/directives.html).
19+
## HtmlDocCk Directives
1820

19-
All `PATH`s in directives are relative to the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`),
20-
so it is conventional to use a `#![crate_name = "foo"]` attribute to avoid
21-
having to write a long crate name multiple times.
22-
To avoid repetition, `-` can be used in any `PATH` argument to re-use the previous `PATH` argument.
21+
Directives to HtmlDocCk are assertions that place constraints on the generated HTML.
22+
They look similar to those given to `compiletest` in that they take the form of `//@` comments
23+
but ultimately, they are completey distinct and processed by different programs.
2324

24-
All arguments take the form of quoted strings
25-
(both single and double quotes are supported),
26-
with the exception of `COUNT` and the special `-` form of `PATH`.
25+
[XPath] is used to query parts of the HTML document tree.
26+
27+
**Introductory example**:
28+
29+
```rust,ignore (illustrative)
30+
//@ has file/type.Alias.html
31+
//@ has - '//*[@class="rust item-decl"]//code' 'type Alias = Option<i32>;'
32+
pub type Alias = Option<i32>;
33+
```
34+
35+
Here, we check that documentation generated for crate `file` contains a page for the
36+
public type alias `Alias` where the code block that is found at the top contains the
37+
expected rendering of the item. The `//*[@class="rust item-decl"]//code` is an XPath
38+
expression.
2739

28-
Directives are assertions that place constraints on the generated HTML.
40+
Conventionally, you place these directives directly above the thing they are meant to test.
41+
Technically speaking however, they don't need to be as HtmlDocCk only looks for the directives.
2942

30-
All directives (except `files`) can be negated by putting a `!` in front of their name.
43+
All directives take a `PATH` argument.
44+
To avoid repetition, `-` can be passed to it to re-use the previous `PATH` argument.
45+
Since the path contains the name of the crate, it is conventional to add a
46+
`#![crate_name = "foo"]` attribute to the crate root to shorten the resulting path.
47+
48+
All arguments take the form of shell-style (single or double) quoted strings,
49+
with the exception of `COUNT` and the special `-` form of `PATH`.
50+
51+
All directives (except `files`) can be *negated* by putting a `!` in front of their name.
52+
Before you add negated directives, please read about [their caveats](#caveats).
3153

3254
Similar to shell commands,
3355
directives can extend across multiple lines if their last char is `\`.
3456
In this case, the start of the next line should be `//`, with no `@`.
3557

36-
For example, `//@ !has 'foo/struct.Bar.html'` checks that crate `foo` does not have a page for a struct named `Bar` in the crate root.
58+
Use the special string `{{channel}}` in XPaths, `PATTERN` arguments and [snapshot files](#snapshot)
59+
if you'd like to refer to the URL `https://doc.rust-lang.org/CHANNEL` where `CHANNEL` refers to the
60+
current release channel (e.g, `stable` or `nightly`).
61+
62+
Listed below are all possible directives:
63+
64+
[XPath]: https://en.wikipedia.org/wiki/XPath
3765

3866
### `has`
3967

40-
Usage 1: `//@ has PATH`
41-
Usage 2: `//@ has PATH XPATH PATTERN`
68+
> Usage 1: `//@ has PATH`
4269
43-
In the first form, `has` checks that a given file exists.
70+
Check that the file given by `PATH` exists.
4471

45-
In the second form, `has` is an alias for `matches`,
46-
except `PATTERN` is a whitespace-normalized[^1] string instead of a regex.
72+
> Usage 2: `//@ has PATH XPATH PATTERN`
4773
48-
### `matches`
74+
Checks that the text of each element / attribute / text selected by `XPATH` in the
75+
whitespace-normalized[^1] file given by `PATH` matches the
76+
(also whitespace-normalized) string `PATTERN`.
77+
78+
**Tip**: If you'd like to avoid whitespace normalization and/or if you'd like to match with a regex,
79+
use `matches` instead.
4980

50-
Usage: `//@ matches PATH XPATH PATTERN`
81+
### `hasraw`
5182

52-
Checks that the text of each element selected by `XPATH` in `PATH` matches the python-flavored regex `PATTERN`.
83+
> Usage: `//@ hasraw PATH PATTERN`
5384
54-
### `matchesraw`
85+
Checks that the contents of the whitespace-normalized[^1] file given by `PATH`
86+
matches the (also whitespace-normalized) string `PATTERN`.
5587

56-
Usage: `//@ matchesraw PATH PATTERN`
88+
**Tip**: If you'd like to avoid whitespace normalization and / or if you'd like to match with a
89+
regex, use `matchesraw` instead.
5790

58-
Checks that the contents of the file `PATH` matches the regex `PATTERN`.
91+
### `matches`
5992

60-
### `hasraw`
93+
> Usage: `//@ matches PATH XPATH PATTERN`
6194
62-
Usage: `//@ hasraw PATH PATTERN`
95+
Checks that the text of each element / attribute / text selected by `XPATH` in the
96+
file given by `PATH` matches the Python-flavored[^2] regex `PATTERN`.
6397

64-
Same as `matchesraw`, except `PATTERN` is a whitespace-normalized[^1] string instead of a regex.
98+
### `matchesraw`
99+
100+
> Usage: `//@ matchesraw PATH PATTERN`
101+
102+
Checks that the contents of the file given by `PATH` matches the
103+
Python-flavored[^2] regex `PATTERN`.
65104

66105
### `count`
67106

68-
Usage: `//@ count PATH XPATH COUNT`
107+
> Usage: `//@ count PATH XPATH COUNT`
69108
70-
Checks that there are exactly `COUNT` matches for `XPATH` within the file `PATH`.
109+
Checks that there are exactly `COUNT` matches for `XPATH` within the file given by `PATH`.
71110

72111
### `snapshot`
73112

74-
Usage: `//@ snapshot NAME PATH XPATH`
113+
> Usage: `//@ snapshot NAME PATH XPATH`
75114
76-
Creates a snapshot test named NAME.
77-
A snapshot test captures a subtree of the DOM, at the location
78-
determined by the XPath, and compares it to a pre-recorded value
79-
in a file. The file's name is the test's name with the `.rs` extension
80-
replaced with `.NAME.html`, where NAME is the snapshot's name.
115+
Checks that the element / text selected by `XPATH` in the file given by `PATH` matches the
116+
pre-recorded subtree or text (the "snapshot") in file `FILE_STEM.NAME.html` where `FILE_STEM`
117+
is the file stem of the test file.
81118

82-
htmldocck supports the `--bless` option to accept the current subtree
83-
as expected, saving it to the file determined by the snapshot's name.
84-
compiletest's `--bless` flag is forwarded to htmldocck.
119+
Pass the `--bless` option to `compiletest` to accept the current subtree/text as expected.
120+
This will overwrite the aforementioned file (or create it if it doesn't exist). It will
121+
automatically normalize the channel-dependent URL `https://doc.rust-lang.org/CHANNEL` to
122+
the special string `{{channel}}`.
85123

86124
### `has-dir`
87125

88-
Usage: `//@ has-dir PATH`
126+
> Usage: `//@ has-dir PATH`
89127
90-
Checks for the existence of directory `PATH`.
128+
Checks for the existence of the directory given by `PATH`.
91129

92130
### `files`
93131

94-
Usage: `//@ files PATH ENTRIES`
132+
> Usage: `//@ files PATH ENTRIES`
133+
134+
Checks that the directory given by `PATH` contains exactly `ENTRIES`.
135+
`ENTRIES` is a Python-like list of strings inside a quoted string.
136+
137+
**Example**: `//@ files "foo/bar" '["index.html", "sidebar-items.js"]'`
138+
139+
[^1]: Whitespace normalization means that all spans of consecutive whitespace are replaced with a single space.
140+
[^2]: They are Unicode aware (flag `UNICODE` is set), match case-sensitively and in single-line mode.
141+
142+
## Compiletest Directives (Brief)
143+
144+
As mentioned in the introduction, you also have access to [compiletest directives].
145+
Most importantly, they allow you to register auxiliary crates and
146+
to pass flags to the `rustdoc` binary under test.
147+
It's *strongly recommended* to read that chapter if you don't know anything about them yet.
148+
149+
Here are some details that are relevant to this test suite specifically:
95150

96-
Checks that the directory `PATH` contains exactly `ENTRIES`.
97-
`ENTRIES` is a python list of strings inside a quoted string,
98-
as if it were to be parsed by `eval`.
99-
(note that the list is actually parsed by `shlex.split`,
100-
so it cannot contain arbitrary python expressions).
151+
* While you can use both `//@ compile-flags` and `//@ doc-flags` to pass flags to `rustdoc`,
152+
prefer to user the latter to show intent. The former is meant for `rustc`.
153+
* Add `//@ build-aux-docs` to the test file that has auxiliary crates to not only compile the
154+
auxiliaries with `rustc` but to also document them with `rustdoc`.
101155

102-
Example: `//@ files "foo/bar" '["index.html", "sidebar-items.js"]'`
156+
## Caveats
103157

104-
[^1]: Whitespace normalization means that all spans of consecutive whitespace are replaced with a single space. The files themselves are also whitespace-normalized.
158+
Testing for the absence of an element or a piece of text is quite fragile and not very future proof.
159+
160+
It's not unusual that the *shape* of the generated HTML document tree changes from time to time.
161+
This includes for example renamings of CSS classes.
162+
163+
Whenever that happens, *positive* checks will either continue to match the intended element /
164+
attribute / text (if their XPath expression is general / loose enough) and
165+
thus continue to test the correct thing or they won't in which case they would fail thereby
166+
forcing the author of the change to look at them.
167+
168+
Compare that to *negative* checks (e.g., `//@ !has PATH XPATH PATTERN`) which won't fail if their
169+
XPath expression "no longer" matches. The author who changed "the shape" thus won't get notified and
170+
as a result someone else can unintentionally reintroduce `PATTERN` into the generated docs without
171+
the original negative check failing.
172+
173+
**Note**: Please avoid the use of *negated* checks!
174+
175+
**Tip**: If you can't avoid it, please **always** pair it with an analogous positive check in the
176+
immediate vicinity, so people changing "the shape" have a chance to notice and to update the
177+
negated check!
105178

106179
## Limitations
107-
`htmldocck.py` uses the xpath implementation from the standard library.
180+
181+
HtmlDocCk uses the XPath implementation from the Python standard library.
108182
This leads to several limitations:
183+
109184
* All `XPATH` arguments must start with `//` due to a flaw in the implementation.
110185
* Many XPath features (functions, axies, etc.) are not supported.
111186
* Only well-formed HTML can be parsed (hopefully rustdoc doesn't output mismatched tags).
112187

188+
Furthmore, compiletest [revisions] are not supported.
189+
190+
[revisions]: ../tests/compiletest.md#revisions
191+
[compiletest directives]: ../tests/directives.md

‎src/rustdoc.md

Lines changed: 14 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -67,43 +67,29 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
6767

6868
## Code structure
6969

70-
* All paths in this section are relative to `src/librustdoc` in the rust-lang/rust repository.
70+
All paths in this section are relative to `src/librustdoc/` in the rust-lang/rust repository.
71+
7172
* Most of the HTML printing code is in `html/format.rs` and `html/render/mod.rs`.
72-
It's in a bunch of `fmt::Display` implementations and supplementary
73-
functions.
74-
* The types that got `Display` impls above are defined in `clean/mod.rs`, right
75-
next to the custom `Clean` trait used to process them out of the rustc HIR.
73+
It's in a bunch of functions returning `impl std::fmt::Display`.
74+
* The data types that get rendered by the functions mentioned above are defined in `clean/types.rs`.
75+
The functions responsible for creating them from the `HIR` and the `rustc_middle::ty` IR
76+
live in `clean/mod.rs`.
7677
* The bits specific to using rustdoc as a test harness are in
7778
`doctest.rs`.
7879
* The Markdown renderer is loaded up in `html/markdown.rs`, including functions
7980
for extracting doctests from a given block of Markdown.
8081
* Frontend CSS and JavaScript are stored in `html/static/`.
82+
* Re. JavaScript, type annotations are written using [TypeScript-flavored JSDoc]
83+
comments and an external `.d.ts` file.
84+
This way, the code itself remains plain, valid JavaScript.
85+
We only use `tsc` as a linter.
8186

82-
## Tests
87+
[TypeScript-flavored JSDoc]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html
8388

84-
* Tests on search engine and index are located in `tests/rustdoc-js` and `tests/rustdoc-js-std`.
85-
The format is specified
86-
[in the search guide](rustdoc-internals/search.md#testing-the-search-engine).
87-
* Tests on the "UI" of rustdoc (the terminal output it produces when run) are in
88-
`tests/rustdoc-ui`
89-
* Tests on the "GUI" of rustdoc (the HTML, JS, and CSS as rendered in a browser)
90-
are in `tests/rustdoc-gui`. These use a [NodeJS tool called
91-
browser-UI-test](https://github.com/GuillaumeGomez/browser-UI-test/) that uses
92-
puppeteer to run tests in a headless browser and check rendering and
93-
interactivity. For information on how to write this form of test,
94-
see [`tests/rustdoc-gui/README.md`][rustdoc-gui-readme]
95-
as well as [the description of the `.goml` format][goml-script]
96-
* Tests on the structure of rustdoc HTML output are located in `tests/rustdoc`,
97-
where they're handled by the test runner of bootstrap and
98-
the supplementary script `src/etc/htmldocck.py`.
99-
[These tests have several extra directives available to them](./rustdoc-internals/rustdoc-test-suite.md).
100-
* Additionally, JavaScript type annotations are written using [TypeScript-flavored JSDoc]
101-
comments and an external d.ts file. The code itself is plain, valid JavaScript; we only
102-
use tsc as a linter.
89+
## Tests
10390

104-
[TypeScript-flavored JSDoc]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html
105-
[rustdoc-gui-readme]: https://github.com/rust-lang/rust/blob/master/tests/rustdoc-gui/README.md
106-
[goml-script]: https://github.com/GuillaumeGomez/browser-UI-test/blob/master/goml-script.md
91+
`rustdoc`'s integration tests are split across several test suites.
92+
See [Rustdoc tests suites](tests/compiletest.md#rustdoc-test-suites) for more details.
10793

10894
## Constraints
10995

‎src/tests/ci.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -186,9 +186,11 @@ Note that if you start the default try job using `@bors try`, it will skip build
186186
Multiple try builds can execute concurrently across different PRs.
187187
188188
<div class="warning">
189-
bors identify try jobs by commit hash. This means that if you have two PRs
189+
190+
Bors identifies try jobs by commit hash. This means that if you have two PRs
190191
containing the same (latest) commits, running `@bors try` will result in the
191192
*same* try job and it really confuses `bors`. Please refrain from doing so.
193+
192194
</div>
193195
194196
[rustc-perf]: https://github.com/rust-lang/rustc-perf

‎src/tests/compiletest.md

Lines changed: 22 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -56,6 +56,9 @@ incremental compilation. The various suites are defined in
5656

5757
The following test suites are available, with links for more information:
5858

59+
[`tests`]: https://github.com/rust-lang/rust/blob/master/tests
60+
[`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs
61+
5962
### Compiler-specific test suites
6063

6164
| Test suite | Purpose |
@@ -71,26 +74,31 @@ The following test suites are available, with links for more information:
7174
| [`mir-opt`](#mir-opt-tests) | Check MIR generation and optimizations |
7275
| [`coverage`](#coverage-tests) | Check coverage instrumentation |
7376
| [`coverage-run-rustdoc`](#coverage-tests) | `coverage` tests that also run instrumented doctests |
77+
| [`crashes`](#crashes-tests) | Check that the compiler ICEs/panics/crashes on certain inputs to catch accidental fixes |
7478

7579
### General purpose test suite
7680

7781
[`run-make`](#run-make-tests) are general purpose tests using Rust programs.
7882

7983
### Rustdoc test suites
8084

81-
See [Rustdoc tests](../rustdoc.md#tests) for more details.
85+
| Test suite | Purpose |
86+
|--------------------------------------|--------------------------------------------------------------------------|
87+
| [`rustdoc`][rustdoc-html-tests] | Check HTML output of `rustdoc` |
88+
| [`rustdoc-gui`][rustdoc-gui-tests] | Check `rustdoc`'s GUI using a web browser |
89+
| [`rustdoc-js`][rustdoc-js-tests] | Check `rustdoc`'s search engine and index |
90+
| [`rustdoc-js-std`][rustdoc-js-tests] | Check `rustdoc`'s search engine and index on the std library docs |
91+
| [`rustdoc-json`][rustdoc-json-tests] | Check JSON output of `rustdoc` |
92+
| `rustdoc-ui` | Check terminal output of `rustdoc` ([see also](ui.md)) |
8293

83-
| Test suite | Purpose |
84-
|------------------|--------------------------------------------------------------------------|
85-
| `rustdoc` | Check `rustdoc` generated files contain the expected documentation |
86-
| `rustdoc-gui` | Check `rustdoc`'s GUI using a web browser |
87-
| `rustdoc-js` | Check `rustdoc` search is working as expected |
88-
| `rustdoc-js-std` | Check rustdoc search is working as expected specifically on the std docs |
89-
| `rustdoc-json` | Check JSON output of `rustdoc` |
90-
| `rustdoc-ui` | Check terminal output of `rustdoc` |
94+
Some rustdoc-specific tests can also be found in `ui/rustdoc/`.
95+
These check rustdoc-related or -specific lints that (also) run as part of `rustc`, not (only) `rustdoc`.
96+
Run-make tests pertaining to rustdoc are typically named `run-make/rustdoc-*/`.
9197

92-
[`tests`]: https://github.com/rust-lang/rust/blob/master/tests
93-
[`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs
98+
[rustdoc-html-tests]: ../rustdoc-internals/rustdoc-test-suite.md
99+
[rustdoc-gui-tests]: ../rustdoc-internals/rustdoc-gui-test-suite.md
100+
[rustdoc-js-tests]: ../rustdoc-internals/search.md#testing-the-search-engine
101+
[rustdoc-json-tests]: ../rustdoc-internals/rustdoc-json-test-suite.md
94102

95103
### Pretty-printer tests
96104

@@ -107,7 +115,7 @@ default behavior without any commands is to:
107115
2. Run `rustc -Zunpretty=normal` on the output of the previous step.
108116
3. The output of the previous two steps should be the same.
109117
4. Run `rustc -Zno-codegen` on the output to make sure that it can type check
110-
(this is similar to running `cargo check`).
118+
(similar to `cargo check`).
111119

112120
If any of the commands above fail, then the test fails.
113121

@@ -438,7 +446,9 @@ To work around this when working on a particular test, temporarily create a
438446
with these contents:
439447

440448
<div class="warning">
449+
441450
Be careful not to add this `Cargo.toml` or its `Cargo.lock` to your actual PR!
451+
442452
</div>
443453

444454
```toml

‎src/tests/directives.md

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -202,6 +202,7 @@ settings:
202202
`//@ needs-crate-type: cdylib, proc-macro` will cause the test to be ignored
203203
on `wasm32-unknown-unknown` target because the target does not support the
204204
`proc-macro` crate type.
205+
- `needs-target-std` — ignores if target platform does not have std support.
205206

206207
The following directives will check LLVM support:
207208

@@ -248,25 +249,38 @@ ignoring debuggers.
248249
| `no-prefer-dynamic` | Don't use `-C prefer-dynamic`, don't build as a dylib via a `--crate-type=dylib` preset flag | `ui`, `crashes` | N/A |
249250

250251
<div class="warning">
252+
251253
Tests (outside of `run-make`) that want to use incremental tests not in the
252254
incremental test-suite must not pass `-C incremental` via `compile-flags`, and
253255
must instead use the `//@ incremental` directive.
254256

255257
Consider writing the test as a proper incremental test instead.
258+
256259
</div>
257260

258261
### Rustdoc
259262

260263
| Directive | Explanation | Supported test suites | Possible values |
261264
|-------------|--------------------------------------------------------------|------------------------------------------|---------------------------|
262-
| `doc-flags` | Flags passed to `rustdoc` when building the test or aux file | `rustdoc`, `rustdoc-js`, `rustdoc-json` | Any valid `rustdoc` flags |
265+
| `doc-flags` | Flags passed to `rustdoc` when building the test or aux file | `rustdoc`, `rustdoc-js`, `rustdoc-json` | Any valid `rustdoc` flags |
263266

264267
<!--
265268
**FIXME(rustdoc)**: what does `check-test-line-numbers-match` do?
266269
Asked in
267270
<https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/What.20is.20the.20.60check-test-line-numbers-match.60.20directive.3F>.
268271
-->
269272

273+
#### Test-suite-specific directives
274+
275+
The test suites [`rustdoc`][rustdoc-html-tests], [`rustdoc-js`/`rustdoc-js-std`][rustdoc-js-tests]
276+
and [`rustdoc-json`][rustdoc-json-tests] each feature an additional set of directives whose basic
277+
syntax resembles the one of compiletest directives but which are ultimately read and checked by
278+
separate tools. For more information, please read their respective chapters as linked above.
279+
280+
[rustdoc-html-tests]: ../rustdoc-internals/rustdoc-test-suite.md
281+
[rustdoc-js-tests]: ../rustdoc-internals/search.html#testing-the-search-engine
282+
[rustdoc-json-tests]: ../rustdoc-internals/rustdoc-json-test-suite.md
283+
270284
### Pretty printing
271285

272286
See [Pretty-printer](compiletest.md#pretty-printer-tests).

‎src/tests/minicore.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,11 @@ ui/codegen/assembly test suites. It provides `core` stubs for tests that need to
77
build for cross-compiled targets but do not need/want to run.
88

99
<div class="warning">
10+
1011
Please note that [`minicore`] is only intended for `core` items, and explicitly
1112
**not** `std` or `alloc` items because `core` items are applicable to a wider
1213
range of tests.
14+
1315
</div>
1416

1517
A test can use [`minicore`] by specifying the `//@ add-core-stubs` directive.

‎src/tests/running.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,7 @@ development because it takes a really long time. For local development, see the
88
subsection after on how to run a subset of tests.
99

1010
<div class="warning">
11+
1112
Running plain `./x test` will build the stage 1 compiler and then run the whole
1213
test suite. This not only include `tests/`, but also `library/`, `compiler/`,
1314
`src/tools/` package tests and more.
@@ -16,6 +17,7 @@ You usually only want to run a subset of the test suites (or even a smaller set
1617
of tests than that) which you expect will exercise your changes. PR CI exercises
1718
a subset of test collections, and merge queue CI will exercise all of the test
1819
collection.
20+
1921
</div>
2022

2123
```text
@@ -116,8 +118,10 @@ By listing which test suites you want to run,
116118
you avoid having to run tests for components you did not change at all.
117119

118120
<div class="warning">
121+
119122
Note that bors only runs the tests with the full stage 2 build; therefore, while
120123
the tests **usually** work fine with stage 1, there are some limitations.
124+
121125
</div>
122126

123127
### Run all tests using a stage 2 compiler

‎src/tests/ui.md

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -220,8 +220,12 @@ negligible (i.e. there is no semantic difference between `//~ ERROR` and
220220
`//~ERROR` although the former is more common in the codebase).
221221

222222
`~? <diagnostic kind>` (example being `~? ERROR`)
223-
is used to match diagnostics without line information.
224-
These can be placed on any line in the test file, but are conventionally placed at the end.
223+
is used to match diagnostics _without_ line info at all,
224+
or where the line info is outside the main test file[^main test file].
225+
These annotations can be placed on any line in the test file.
226+
227+
[^main test file]: This is a file that has the `~?` annotations,
228+
as distinct from aux files, or sources that we have no control over.
225229

226230
### Error annotation examples
227231

‎triagebot.toml

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -72,6 +72,23 @@ days-threshold = 7
7272
# Documentation at: https://forge.rust-lang.org/triagebot/pr-assignment.html
7373
[assign]
7474

75+
# NOTE: do not add `[assign.owners]` if we still wish to keep the opt-in
76+
# reviewer model, as `[assign.owners]` will cause triagebot auto-reviewer
77+
# assignment to kick in.
78+
79+
# Custom PR welcome message for when no auto reviewer assignment is performed
80+
# and no explicit manual reviewer selection is made.
81+
# Documentation at: https://forge.rust-lang.org/triagebot/pr-assignment.html#custom-welcome-messages
82+
[assign.custom_welcome_messages]
83+
welcome-message = ""
84+
welcome-message-no-reviewer = """\
85+
Thanks for the PR. If you have write access, feel free to merge this PR if it \
86+
does not need reviews. You can request a review using `r? rustc-dev-guide` or \
87+
`r? <username>`.
88+
"""
89+
90+
# Groups for `r? <group>`.
91+
# Documentation at: https://forge.rust-lang.org/triagebot/pr-assignment.html#usage
7592
# Keep members alphanumerically sorted.
7693
[assign.adhoc_groups]
7794
rustc-dev-guide = [

0 commit comments

Comments
 (0)
Please sign in to comment.