Allowing the Xcode version to "float" based on whatever default GitHub
selects creates an unreliable environment. When GitHub changes the
default, we can have multiple jobs in the same run using different
versions as it rolls out across machines. It can also cause oscillation
between runs as different machines are used. It also causes
unpredictable timing when the updates happen.
This change helps ensure that the version that is used is pinned. The
downside is that it requires manually bumping the version, and the risk
that if we take too long, older Xcodes will be removed and that will
break the build.
This seems to fix two sporadic errors that have been appearing in CI.
One is an issue with cmake being unable to verify that cmake is able to
build a simple test program. The other is a `invalid r_symbolnum`
linking error when trying to build one of cranelift's tests.
This is intended as a temporary fix until we can figure out how to
resolve those issues.
Don't use bashism in checktools.sh
`if [[` doesn't work because this is a `/bin/sh` script. We were never running the success side of this `if` at all.
Bump Fuchsia, build tests, and use 8 core bots
- Build Fuchsia on 8 cores instead of 16
- Skip building cranelift for Fuchsia
- Bump Fuchsia (includes building tests)
This includes a change to the upstream build_fuchsia_from_rust_ci script that builds a minimal set of tests, to improve coverage on this builder. This would have caught https://github.com/rust-lang/rust-clippy/issues/11952 and #119593.
See prior discussion on #119400 about building on 8 cores instead of 16. This PR combines changes from that and #119399, plus clean up.
r? `@Mark-Simulacrum`
in particular, this makes the `c` feature for compiler-builtins an explicit opt-in, rather than silently detected by whether `llvm-project` is checked out on disk.
exposing this is necessary because the `cc` crate doesn't support cross-compiling to MSVC, and we want people to be able to run `x check --target foo` regardless of whether they have a c toolchain available.
this also uses the new option in CI, where we *do* want to optimize compiler_builtins.
the new option is off by default for the `dev` channel and on otherwise.
This commit temporarily reverts the addition of M1 runners on GitHub
Actions to work around a billing issue related to their beta. It also
removes the `aarch64-apple` job, which was only added after the addition
of M1 runners. Since it has never been tested on the prior hardware, we
are skipping the tests to reduce the risk of build failures.
Remove usage of deprecated `missing-tools` bootstrap flag
This PR removes the usage of `--enable-missing-tools` in CI, as this config option is no longer used. It also removes `dist.missing-tools` config completely.
Let me know which commits should I remove (if any).
Fixes: https://github.com/rust-lang/rust/issues/79249
r? `@onur-ozkan`
improve container runner script
First commit fixes#118930
Second commit is mostly for development purposes. In read-only mode submodules cannot be initialized due to access limitations (see the log below), which means that tools cannot be built.
```sh
Updating submodule src/tools/cargo
error: could not lock config file .git/config: Read-only file system
error: could not lock config file .git/config: Read-only file system
fatal: Failed to register url for submodule path 'src/tools/cargo'
error: could not lock config file .git/config: Read-only file system
error: could not lock config file .git/config: Read-only file system
fatal: Failed to register url for submodule path 'src/tools/cargo'
Build completed unsuccessfully in 0:00:00
```
The compiler-builtins for RISC-V are missing some key functions, such as
__bswapsi2 [1].
We can't just pull in the LLVM compiler-rt builtins as the rust-lang/rust
distribution container doesn't have a C compiler [2].
This patch adds RISC-V C compilers to the CI Dockerfile as the first
step towards enabling LLVM compiler-rt builtins for RISC-V Rust.
1: https://github.com/rust-lang/compiler-builtins/issues/350
2: e4f46b91ca
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Let `reuse` look inside git submodules
Changes `collect-license-metadata` and `generate-copyright` so they can now look at the git submodules.
Unfortunately `reuse` chokes on the LLVM submodule - it finds the word "Copyright" or the unicode copyright symbol in all kinds of places, including UTF-8 test cases. The `reuse` tool expressly won't let you ignore folders, so we let it scan everything and then strip out the LLVM sub-folder in post. Instead, we add in a hand-curated list of copyright information gleaned by reading the LLVM codebase carefully, which is stored in `.reuse/dep5` in Debian format where `reuse` can find and use it.
The `.reuse/dep5` continues to track copyright info for files in the tree that do not have SPDX metadata in them (i.e. all of them)
Re-enable `rustc_codegen_gcc` tests in CI
When #117947 dropped llvm-15 from CI, we neglected to copy #117313's changes to enable `rustc_codegen_gcc` testing to the new base llvm-16. This is now restored, as well as copying the setup to llvm-17 as well so we hopefully won't miss it next time.
In addition, due to case mismatch in `$extra_env` updates in `docker/run.sh`, I think it wasn't actually getting enabled before, but this should now be fixed. I also avoided the linker hack for `libgccjit.so` that was present before, because that's not needed if the version matches the base `gcc` used for linking.
r? GuillaumeGomez
Expand Miri's BorTag GC to a Provenance GC
As suggested in https://github.com/rust-lang/miri/issues/3080#issuecomment-1732505573
We previously solved memory growth issues associated with the Stacked Borrows and Tree Borrows runtimes with a GC. But of course we also have state accumulation associated with whole allocations elsewhere in the interpreter, and this PR starts tackling those.
To do this, we expand the visitor for the GC so that it can visit a BorTag or an AllocId. Instead of collecting all live AllocIds into a single HashSet, we just collect from the Machine itself then go through an accessor `InterpCx::is_alloc_live` which checks a number of allocation data structures in the core interpreter. This avoids the overhead of all the inserts that collecting their keys would require.
r? ``@RalfJung``
deprecate `if-available` value of `download-ci-llvm`
This PR deprecates the use of the `if-available` value for `download-ci-llvm` since `if-unchanged` serves the same purpose when no changes are detected. In cases where changes are present, it is assumed that compiling LLVM is acceptable (otherwise, why make changes there?).
This was probably missing in the #110087 issue before.
cc `@RalfJung`
