* Move 'force-unstable-if-unmarked' to the bootstrapping chapter
* Document how to stabilize a library feature
Note that features can't be stabilized until they go through FCP and
that FCP happens on the tracking issue, not the PR.
* Fix wrong glob
By default `**` behaves the same as two `*` side by side, i.e. it only
globs file paths, not directories. `shopt -s globstar` needs to be set
for it to mean a directory. I didn't notice this before now because
`globstar` is set by default in interactive mode, but not otherwise.
`download-ci-llvm` is available and enabled by default for all tier 1
platforms, so there is no need to change it. Using system LLVM over CI
llvm is still supported, but is not recommended. Building LLVM from
source is still supported.
This also notes that you need to explicitly disable downloading LLVM
when updating the submodule.
Document the newly added `x` binary that wraps `x.py`, which can be
installed system-wide, and can be run from any subdirectory of a rust
repo checkout.
This makes the compiler faster to running without sacrificing too much
performance. It still shows logging so contributors aren't confused by
`debug!` doing nothing.
This is a companion to [this PR](https://github.com/rust-lang/rust/pull/76356), which deals with including functionality for automatically running `tidy --bless` on each commit.
Undo editor auto-formatting and clarify git hook renaming
a word
Phrasing
Apply suggestions from code review
Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com>
* Explain stages in terms of the compiler currently running
- Address some confusing points
+ stage N+1 -> stage N artifacts
+ Use more likely examples of an ABI break
+ stage N -> stage N compiler
- Mention why rustc occasionally uses `cfg(bootstrap)`
- Note that stage1 is built using two different versions
- Add lots of examples
+ `test src/test/ui` and `test compiler/rustc` run different compilers 😢
+ Separate examples of what to do from examples of what not to do
- 'ship stage 1 artifacts' -> 'ship stage 2 compiler'
This is hopefully less confusing.
* build -> x.py build
* Add section on build artifacts
* Improve wording
Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com>
* uplifted -> assembled
Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com>
* Update prerequisites, with an eye towards windows
* Address review comments
- Say version of MSVC needed
- Link to more details windows section
- Fix grammar
Previously, 'How to build and run' had a long section on the different
stages of boostrap. But new contributors aren't interested in bootstrap;
they want to start their build (because they heard it takes forever and
want to start it so they aren't waiting more than necessary).
This moves the section on stages into the bootstrapping page, and links
there instead of discussing it on the main page.
Several of the commands on 'how to build' use python.
But we haven't yet told the user how to install it!
Do that first before going into detail on how x.py works.