Update sysinfo version to 0.31.2
I needed to update `memchr` version (which was pinned in 36a16798f7). So let's see if it triggers the linker issue.
try-job: x86_64-mingw
improve bootstrap to allow selecting llvm tools individually
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.
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.
