You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/doc/rustc-dev-guide/src/early-late-parameters.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,12 @@
3
3
4
4
> **NOTE**: This chapter largely talks about early/late bound as being solely relevant when discussing function item types/function definitions. This is potentially not completely true, async blocks and closures should likely be discussed somewhat in this chapter.
5
5
6
+
See also these blog posts from when the distinction between early and late bound parameters was
7
+
introduced: [Intermingled parameter lists] and [Intermingled parameter lists, take 2].
[Intermingled parameter lists, take 2]: https://smallcultfollowing.com/babysteps/blog/2013/11/04/intermingled-parameter-lists/
11
+
6
12
## What does it mean to be "early" bound or "late" bound
7
13
8
14
Every function definition has a corresponding ZST that implements the `Fn*` traits known as a [function item type][function_item_type]. This part of the chapter will talk a little bit about the "desugaring" of function item types as it is useful context for explaining the difference between early bound and late bound generic parameters.
Copy file name to clipboardExpand all lines: src/doc/rustc-dev-guide/src/tests/compiletest.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -836,3 +836,20 @@ In CI, compare modes are only used in one Linux builder, and only with the follo
836
836
Note that compare modes are separate to [revisions](#revisions).
837
837
All revisions are tested when running `./x test tests/ui`, however compare-modes must be
838
838
manually run individually via the `--compare-mode` flag.
839
+
840
+
## Parallel frontend
841
+
842
+
Compiletest can be run with the `--parallel-frontend-threads` flag to run the compiler in parallel mode.
843
+
This can be used to check that the compiler produces the same output in parallel mode as in non-parallel mode, and to check for any issues that might arise in parallel mode.
844
+
845
+
To run the tests in parallel mode, you need to pass the `--parallel-frontend-threads` CLI flag:
846
+
847
+
```bash
848
+
./x test tests/ui -- --parallel-frontend-threads=N --iteration-count=M
849
+
```
850
+
851
+
Where `N` is the number of threads to use for the parallel frontend, and `M` is the number of times to run each test in parallel mode (to increase the chances of catching any non-determinism).
852
+
853
+
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.
854
+
855
+
The parallel frontend is available in UI tests only at the moment, and is not currently supported in other test suites.
0 commit comments