-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rollup merge of #73883 - ehuss:rustdoc-stage-previous, r=Mark-Simulacrum
Compile rustdoc less often. Previously rustdoc was built 3 times with `x.py test`: 1. stage2 (using stage1 compiler) for compiletest tests (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for std crate tests (stage0-tools copied to stage1). 3. stage2 test (using stage2 compiler) for rustdoc crate tests and error_index_generator (stage2-tools). This PR removes the majority of number 3, where it will instead use the stage1 compiler, which will share the artifacts from number 1. This matches the behavior of the libstd crate tests. I don't think it is entirely necessary to run the tests using stage2. At `-j2`, the last build step goes from about 300s to 70s on my machine. It's not a huge win, but shaving 4 minutes isn't bad. The other two builds would be pretty difficult (or undesired or impossible) to unify. It looks like std tests use stage1 very intentionally (see `force_use_stage1` and its history), and compiletests use the top stage very intentionally. Unfortunately the linkchecker builds all docs at stage2 (stage2-tools), which means a few build script artifacts are not shared. It's not really clear to me how to fix that (because it uses `default_doc`, there doesn't seem to be any control over the stages). --- For `x.py doc`, rustdoc was previously built three times (with compiler-docs): 1. stage2 (using stage1 compiler) for normal documentation output (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for compiler-docs 3. stage2 (using stage2 compiler) for error_index_generator (stage2-tools) This PR combines these so that they consistently use the "top stage" rustdoc. I don't know why the compiler-docs was written to use stage minus one, but it seems better to be consistent across the doc steps. --- I've tried to test this with a variety of commands (`x.py doc`, `x.py test`, different `--stage` flags, `full-bootstrap`, setting `--target`, etc.) to try to make sure there aren't significant regressions here. It's tricky since there are so many variables, and this stuff is difficult for me to fully understand. Closes #70799 (I think)
- Loading branch information
Showing
4 changed files
with
146 additions
and
34 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters