fix issue with x.py setup running into explicit panic
Fixes problem with [Issue #102555](https://github.com/rust-lang/rust/issues/102555) causing `x.py` setup to fail. Simply requires `rustfmt` be downloaded a little later.
Allow passing rustix_use_libc cfg using RUSTFLAGS
Before this would error with
```
error: unexpected `rustix_use_libc` as condition name
|
= note: `-D unexpected-cfgs` implied by `-D warnings`
= help: was set with `--cfg` but isn't in the `--check-cfg` expected names
```
I'm setting rustix_use_libc when testing bootstrapping rustc with cg_clif as I'm disabling inline asm here.
Change argument handling in `remote-test-server` and add new flags
This PR updates `remote-test-server` to add two new flags:
* `--sequential` disables parallel test execution, accepting one connection at the time instead. We need this for Ferrocene as one of our emulators occasionally deadlocks when running multiple tests in parallel.
* `--bind <ip:port>` allows customizing the IP and port `remote-test-server` binds to, rather than using the default value.
While I was changing the flags, and [after chatting on what to do on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/remote-test-server.20flags), I took this opportunity to cleanup argument handling in `remote-test-server`, which is a breaking change:
* The `verbose` argument has been renamed to the `--verbose` flag.
* The `remote` argument has been removed in favor of the `--bind 0.0.0.0:12345` flag. The only thing the argument did was to change the bound IP to 0.0.0.0, which can easily be replicated with `--bind` and also is not secure as our "remote" default.
I'm also open to keep the old arguments with deprecation warnings.
r? `@Mark-Simulacrum`
Make the `c` feature for `compiler-builtins` an explicit opt-in
Its build script doesn't support cross-compilation. I tried fixing it, but the cc crate itself doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain:
```
error occurred: Failed to find tool. Is `lib.exe` installed?
```
Fixes https://github.com/rust-lang/rust/issues/101172.
The build script for `compiler_builtins` doesn't support cross-compilation. I tried fixing it, but the cc crate itself
doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain:
```
error occurred: Failed to find tool. Is `lib.exe` installed?
```
Rather than trying to fix it or special-case the platforms without bugs,
make it opt-in instead of automatic.
Before this would error with
```
error: unexpected `rustix_use_libc` as condition name
|
= note: `-D unexpected-cfgs` implied by `-D warnings`
= help: was set with `--cfg` but isn't in the `--check-cfg` expected names
```
I'm setting rustix_use_libc when testing bootstrapping rustc with cg_clif as I'm disabling inline asm here.
This restores functionality broken by #98483. Unfortunately, it doesn't
add a test to verify this works, but in this case we notice pretty
quickly as perf uses this functionality and so reports breakage
immediately after merging.
Distribute bootstrap in CI
This pre-compiles bootstrap from source and adds it to the existing `rust-dev` component. There are two main goals here:
1. Make it faster to build rust from source, both the first time and incrementally
2. Make it easier to add non-python entrypoints, since they can call out to bootstrap directly rather than having to figure out the right flags to pre-compile it. This second part is still in a bit of flux, see the tracking issue below for more information.
There are also several changes to make bootstrap able to run on a machine other than the one it was built (particularly around `config.src` and `config.out` detection). I (`@jyn514)` am slightly concerned these will regress unless tested - maybe we should add an automated test that runs bootstrap in a chroot or something? Unclear whether the effort is worth the test coverage.
Helps with https://github.com/rust-lang/rust/issues/94829.
Add `llvm-dis` to the set of tools in `ci-llvm`
The LLVM disassembler is needed for the test introduced in https://github.com/rust-lang/rust/pull/97550.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Distribute rust-docs-json via rustup.
I am not 100% sure on how to treat `rust-json-docs` in `target_host_combination`. I went along with a similar strategy to the one used for `rust-docs`, but looking for guidance there.
Distribute json doc
# Overview
We add a new component, `rust-json-docs`, to distribute the JSON version of rustdoc's output for public compiler crates (i.e. `std`, `alloc`, `proc_macro`, `core` and `test`).
As discussed in #101383, we do not bundle this up as part of the existing `rust-docs` component since `rustdoc`'s JSON format is still unstable.
# Open questions / Doubts
I tried my best, but I never touched this codebase and I couldn't find much documentation on how `dist` works - I pattern-matched existing code, which might have led to some non-sensical choices in the eyes of people more familiar with the codebase. In particular, I am not sure if my choice of adding a new config flag is appropriate or if the decision to build/not build the JSON docs is more appropriately gated by one of the existing flags.
Any suggestion is more than welcome.
Closes#101383
Revert "Copy stage0 binaries into stage0-sysroot"
This reverts PR #101711.
The PR broke the rustc/bootstrap benchmark on rustc-perf, I believe due to the assumption that the stage0 directory exists. Fixing that by just skipping this logic might be reasonable, but I think there's a larger discussion to be had around the right behavior when we don't have a single bin/ directory (when rustc= and cargo= are specified in config.toml). I think it's potentially reasonable to put those binaries (cargo, rustc, rustfmt?) into the bin directory, but for now just want to get us back to a healthy state.
r? `@jyn514` (but would appreciate review from others as this is just a direct revert).
Allow building `rust-analyzer-proc-macro-srv` as a standalone tool
This PR allows building `rust-analyzer-proc-macro-srv` as a standalone tool via `x b proc-macro-srv-cli` (I thought that `x b rust-analyzer-proc-macro-srv` should work, but it doesn't for some reason...). Also this PR adds a copy of `rust-analyzer-proc-macro-srv` binary to `build/{triple}/{stage}/libexec/` when building `rust-analyzer-proc-macro-srv`, so that r-a can pick it up.
This is useful to make r-a (and I assume Intellij IDEA) to expand macros when using a custom, build from source toolchain.
r? ``@jyn514``
[_zulip thread_](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/How.20to.20fix.20.60UnsupportedABI.60.20for.20custom.20toolchains.3F/near/299040175)
Improve handing of env vars during bootstrap process
This CL modifies the handing of env vars during the bootstrap process in two ways:
1. Replaces '-' characters with '_' characters in target names to increase compatibility with different shells
2. Passes Stage0 snapshot compiler related env vars to early invocations of Cargo
Extend list of targets that support dyanmic linking for llvm tools
This commit adds `linux-musl` to the list of targets that support dynamic linking for the LLVM tools.
Pass --cfg=bootstrap for rustdoc for proc_macro crates
This PR does three things:
* First, it passes --cfg=bootstrap on stage 0 for rustdoc invocations on proc_macro crates. This mirrors what we do already for rustc invocations of those, and is needed because cargo doesn't respect RUSTFLAGS or RUSTDOCFLAGS when confronted with a proc macro.
* Second, it marks the bootstrap config variable as expected. This is needed both on later stages where it's not set, but also on stage 0, where it is set.
* Third, it adjusts the comment in the rustc wrapper to better reflect the reason why we set the bootstrap variable as
expected: due to recent changes, setting it as expected
is also required even if the cfg variable is passed: ebf4cc361e .
This was originally added so those doc pages could use the same font
files, but it turns out to be fragile. And those doc pages are just
stubs that link to other pages, so they don't need fancy fonts.
This CL modifies the handing of env vars during the bootstrap process in
two ways:
1. Replaces '-' characters with '_' characters in target names to
increase compatibility with different shells
2. Passes Stage0 snapshot compiler related env vars to early invocations
of Cargo
This commit does three things:
* First, it passes --cfg=bootstrap on stage 0 for rustdoc
invocations on proc_macro crates. This mirrors what we
do already for rustc invocations of those, and is needed
because cargo doesn't respect RUSTFLAGS or RUSTDOCFLAGS
when confronted with a proc macro.
* Second, it marks the bootstrap config variable as expected.
This is needed both on later stages where it's not set,
but also on stage 0, where it is set.
* Third, it adjusts the comment in the rustc wrapper to better
reflect the reason why we set the bootstrap variable as
expected: due to recent changes, setting it as expected
is also required even if the cfg variable is passed: ebf4cc361e .
