Everything works as before, + now bootstrap allows for individually selecting LLVM
tools (e.g., `x dist opt llvm-dis`) to include in the dist artifact.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
`crates` field is handled in the `Step::make_run` just like in any other
`Std` implementation, so we don't need to resolve them in `Std::new`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Since we now handle library crates properly, there's no need to panic for `no_std`
targets anymore.
`x doc library` now generates documentation for the `alloc` crate from standard library.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
This change unifies the `Step::run_make` logic and improves it by skipping
std specific crates for no_std targets.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Update the reference
This updates the reference to use the new mdbook-spec preprocessor, which is a Cargo library inside the reference submodule.
Note that this PR contains a bunch of bootstrap cleanup commits to assist with making sure the submodules are working correctly. All of the cleanup PRs should have a description in their commit. I'd be happy to move those to a separate PR if that makes review easier.
The main changes for the reference are:
- Move the `doc::Reference` bootstrap step out of the generic macro into a custom step.
- This step needs to build rustdoc because the new mdbook-spec plugin uses rustdoc for generating links.
- PATH is updated so that the rustdoc binary can be found.
- rustbook now includes the mdbook-spec plugin as a dependency.
- rustbook enables the mdbook-spec preprocessor.
I did a bunch of testing with the various commands and setups, such as:
- `submodules=true` and `submodules=false`
- having all submodules deinitialized
- not in a git repository
However, there are probably thousands of different permutations of different commands, settings, and environments, so there is a chance I'm missing something.
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of https://github.com/rust-lang/rust/pull/127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just `run`, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
try-job: x86_64-msvc
I misread this one. It is only checking if LLVM needs to be rebuilt.
There is code below that handles the case where it is unable to compute
the stamp if the source is missing.
These are required 100% of the time, but they are almost always required
for any command that runs Cargo in the main workspace.
Ideally, initializing these two standard library submodules would be
lazy and only initialized when required (see
https://github.com/rust-lang/rust/pull/82653). However, it would require
updating these in almost every Step (anything that runs `cargo` in the
main workspace).
If e.g. only stdout is captured, but the caller tries to read stderr, previously
they would get back an empty string. Now the code will explicitly panic when
accessing an uncaptured output stream.
Now there are separate functions for running a command without capturing, running while capturing stdout
and running while capturing everything. This should help avoid situations where stdout/stderr is accessed
when it was not captured.
We were running testing on API 18, which was already out of support for
NDK 25, and some of the ancient behavior in that image was causing
trouble when developing `rustc` features (#120326).
Update to the current LTS NDK 26, and to its minimum supported API 21.
Fixes: #120567
This updates the reference which is now using a new mdbook plugin. This
requires a little extra work than a normal book because the plugin uses
`rustdoc` to generate links to the standard library. It also ensures
that the submodule is available for *any* command that uses rustbook,
since it is now part of the rustbook workspace.
This adds a new method `require_and_update_submodule` to replace
`update_submodule`. This new method will generate an error if the
submodule doesn't actually exist. This replaces some ad-hoc checks that
were performing this function. This helps ensure that a good error
message is always displayed.
This also adds require_and_update_all_submodules which does this for
all submodules.
Ideally this should not have any change other than better error messages
when submodules are missing.
I put this submodule update in the entirely wrong location. I put it in
the `RustcBook` step (for generating src/doc/rustc), when it really
should exist for all steps that use the `Rustbook` tool.
ensure std step before preparing sysroot
When using download-rustc, any stage other than 0 or 1 (e.g., cargo +stage2 build/doc) will fail to find std while compiling on simple rust sources. Ensuring the std step fixes this issue.
r? Kobzol
When using download-rustc, any stage other than 0 or 1 (e.g., cargo +stage2 build/doc) will
fail to find std while compiling on simple rust sources. Ensuring the rustc step fixes
this issue.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
make it possible to disable download-rustc if it's incompatible
Primarily needed by CI runners to avoid handling download-rustc incompatible options one by one on shell scripts.
This will significantly help to #122709.
Fix inclusion of `wasm-component-ld` in dist artifacts
This is another accidental omission from #126967 (in addition to #127867) which fixes an issue where `wasm-component-ld` isn't distributed via rustup just yet because while it's present in the sysroot it's not present in the tarballs.
Primarily needed by CI runners to avoid handling download-rustc incompatible
options one by one on shell scripts.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
This is another accidental omission from #126967 (in addition
to #127867) which fixes an issue where `wasm-component-ld` isn't
distributed via rustup just yet because while it's present in the
sysroot it's not present in the tarballs.
Rewrite `test-float-parse` in Rust
Migrate from the currently broken Rust + Python `test-float-parse` to a Rust implementation. This newer version should be significantly faster (tests execute in parallel with threads, rather than series across multiple processes, which also eliminates the "...the worker processes are leaked and stick around forever" message), and should be significantly easier to extend to the new float types.
Since this is faster and hopefully more stable, we should be able to launch it with `x` and run the faster tests in CI.
With the previous improvements, it is now possible to run float parsing
tests as part of CI. Enable it here.
This only runs a subset of tests, which takes about one minute.
With updates to `test-float-parse`, it is now possible to run as another
Rust tool. Enable check, clippy, and test.
Test runs the unit tests, as well as shorter parsing tests (takes
approximately 1 minute).
use precompiled rustdoc with CI rustc
When CI rustc is enabled and rustdoc sources are unchanged, we can use the precompiled rustdoc from the CI rustc's sysroot. This speeds up bootstrapping quite a lot by avoiding unnecessary rustdoc compilation.
