When running a command like `DESTDIR=foo x.py install` in a completely
clean build directory, this will cause LLVM to be installed into
`DESTDIR`, which then causes the build to fail later when it attempts
to *use* those LLVM files.
Fix cross compilation of LLVM to aarch64 Windows targets
When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.
This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.
If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.
Related issue: #72881
Requires LLVM change: rust-lang/llvm-project#67
When cross-compiling, the LLVM build system recurses to build tools
that need to run on the host system. However, since we pass cmake defines
to set the compiler and target, LLVM still compiles these tools for the
target system, rather than the host. The tools then fail to execute
during the LLVM build.
This change sets defines for the tools that need to run on the
host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build
does not attempt to build them, and instead relies on the tools already built.
If compiling with clang-cl, this change also adds the `--target` option
to specify the target triple. MSVC compilers do not require this, since there
is a separate compiler binary for cross-compilation.
Remove unused RUSTC_DEBUG_ASSERTIONS
Since #73374 the rustc wrapper no longer configures debug assertions
based on RUSTC_DEBUG_ASSERTIONS environment variable.
r? @RalfJung
The current plan is that submodule tracks the `release` branch of
rust-analyzer, which is updated once a week.
rust-analyzer is a workspace (with a virtual manifest), the actual
binary is provide by `crates/rust-analyzer` package.
Note that we intentionally don't add rust-analyzer to `Kind::Test`,
for two reasons.
*First*, at the moment rust-analyzer's test suite does a couple of
things which might not work in the context of rust repository. For
example, it shells out directly to `rustup` and `rustfmt`. So, making
this work requires non-trivial efforts.
*Second*, it seems unlikely that running tests in rust-lang/rust repo
would provide any additional guarantees. rust-analyzer builds with
stable and does not depend on the specifics of the compiler, so
changes to compiler can't break ra, unless they break stability
guarantee. Additionally, rust-analyzer itself is gated on bors, so we
are pretty confident that test suite passes.
Rollup of 10 pull requests
Successful merges:
- #73414 (Implement `slice_strip` feature)
- #73564 (linker: Create GNU_EH_FRAME header by default when producing ELFs)
- #73622 (Deny unsafe ops in unsafe fns in libcore)
- #73684 (add spans to injected coverage counters, extract with CoverageData query)
- #73812 (ast_pretty: Pass some token streams and trees by reference)
- #73853 (Add newline to rustc MultiSpan docs)
- #73883 (Compile rustdoc less often.)
- #73885 (Fix wasm32 being broken due to a NodeJS version bump)
- #73903 (Changes required for rustc/cargo to build for iOS targets)
- #73938 (Optimise fast path of checked_ops with `unlikely`)
Failed merges:
r? @ghost
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)
Remove legacy InnoSetup GUI installer
On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed.
The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very "legacy" at this point.
Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase.
As a result of removing InnoSetup, this closes#24397
bootstrap: Configurable musl libdir
Make it possible to customize the location of musl libdir using
musl-libdir in config.toml, e.g., to use lib64 instead of lib.
rustbuild: Move compiler-builtins build logic to manifest
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
Update mdbook
This updates mdbook to 0.4. The list of changes can be found at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-040. I think the most important one is the change to include fonts with the book instead of using the Google Fonts CDN. This adds a few megabytes of fonts to the docs component. It may be possible to share the fonts across the books, but would take a fair bit of work to make that happen, so I'm not sure if it is necessary.
This also removes mdbook-linkcheck. It is currently not being used, and I don't foresee it going back into use anytime soon. I would prefer not to maintain something that isn't being used, and it removes a very large number of dependencies.
Fortanix SGX target libunwind build process changes
Ticket: https://github.com/fortanix/rust-sgx/issues/174
LLVM related changes (merged): https://github.com/rust-lang/llvm-project/pull/57
Description: libunwind changes needed to run code in sgx environment via rust-sgx.
Target that uses this in rust: x86_64-fortanix-unknown-sgx.
Without this change, rust std for this toolchain is forced to use a precompiled library loaded via environment variable.
With this change we act the same as musl target.
bootstrap: no `config.toml` exists regression
Fixes#73574.
This PR fixes a regression introduced in #73317 where an oversight meant that `config.toml` was assumed to exist.
This commit fixes a regression introduced in #73317 where an oversight
meant that `config.toml` was assumed to exist.
Signed-off-by: David Wood <david@davidtw.co>
Enable LLVM zlib
Compilers may generate ELF objects with compressed sections (although rustc currently doesn't do this). Currently, when linking these with `rust-lld`, you'll get this error:
`rust-lld: error: ...: contains a compressed section, but zlib is not available`
This enables zlib when building LLVM.
RISC-V Emulated Testing
Adds a disabled docker image on which to run RISC-V tests. Based on the armhf image.
Test using
```
./src/ci/docker/run.sh riscv64gc-linux
```
cc: @msizanoen1
Speed up bootstrap a little.
The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation, and this attempts to avoid the extra calls. On my system, a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4.
An overview of the changes:
- Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config).
- Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there, it looks like a mistake or vestigial from previous behavior.
- Remove check for `_shim`, I believe all the `_shim` crates are now gone.
- Remove check for `rustc_` and `*san` for `test::Crate::should_run`, these are no longer dependencies in the `test` tree.
- Use relative paths in `./x.py test -h -v` output.
- Some code cleanup (remove unnecessary `find_compiler_crates`, etc.).
- Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output.
- Some doc comments.
