Use a small runner for msvc-ext2 job
Hopefully this should eliminate the errors from this job. The only question is how long it takes.
try-job: x86_64-msvc-ext2
ci: add a runner for vanilla LLVM 19
Ubuntu 24.10 has `llvm-19` packages that we can start testing with.
The `Dockerfile` is otherwise the same as the `llvm-18` runner.
Distribute rustc_codegen_cranelift for Windows
With support for raw-dylib recently added to cg_clif, and inline assembly support working on Windows for quite a while now, all blockers for distributing cg_clif on Windows that I mentioned in https://github.com/rust-lang/rust/pull/81746#issuecomment-1774099637 are fixed now.
CI: rfl: add more tools and steps
This will add some time for the tool building -- the actual steps should be quick, though, and allows us to cover quite a few more tools and unstable features in use.
Please see the individual commits for a few details.
Cc: `@GuillaumeGomez` `@tgross35`
r? `@Kobzol`
try-job: x86_64-rust-for-linux
enable -Zrandomize-layout in debug CI builds
This builds rustc/libs/tools with `-Zrandomize-layout` on *-debug CI runners.
Only a handful of tests and asserts break with that enabled, which is promising. One test was fixable, the rest is dealt with by disabling them through new cargo features or compiletest directives.
The config.toml flag `rust.randomize-layout` defaults to false, so it has to be explicitly enabled for now.
This particular target does not expand into much code, so it is a good
first candidate to see if we could keep this in the CI.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This change will also remove the current warnings in the build due to
`rustfmt` not being available (for `bindgen` output):
error: 'rustfmt' is not installed for the custom toolchain 'local'.
note: this is a custom toolchain, which cannot use `rustup component add`
help: if you built this toolchain from source, and used `rustup toolchain link`, then you may be able to build the component with `x.py`
Failed to run rustfmt: Internal rustfmt error (non-fatal, continuing)
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Apparently tools like `rustfmt` require it in order to find the right
`librustc_driver.so` without extra tweaks.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
More work on `zstd` compression
r? ``@Kobzol`` as we've discussed this.
This is a draft to show the current approach of supporting zstd in compiletest, and making the tests using it unconditional.
Knowing whether llvm/lld was built with `LLVM_ENABLE_ZSTD` is quite hard, so there are two strategies. There are details in the code, and we can discuss this approach. Until we know the config used to build CI artifacts, it seems our options are somewhat limited in any case.
zlib compression seems always enabled, so we only check this in its dedicated test, allowing the test to ignore errors due to zstd not being supported.
The zstd test is made unconditional in what it tests, by relying on `needs-llvm-zstd` to be ignored when `llvm.libzstd` isn't enabled in `config.toml`.
try-job: x86_64-gnu
try-job: x86_64-msvc
try-job: x86_64-gnu-distcheck
Switch to using the v2 resolver in most workspaces
Pinning the resolver to v1 was done in 5abff3753a ("Explicit set workspace.resolver ...") in order to suppress warnings. Since there is no specific reason not to use the new resolver and since it fixes issues, change to `resolver = "2"` everywhere except library.
Update `crosstool-ng` for loongarch64
The current cross-compilation toolchain for the LoongArch64 target consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils 2.40 has known issues that in broken binaries without any error reports:
- https://github.com/rust-lang/rust/issues/121289
- https://github.com/cross-rs/cross/issues/1538
This patch upgrades the cross-compilation toolchain for the LoongArch64 target to resolve these issues.
- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42
The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36 distribution, and no issues have been identified.
try-job: dist-loongarch64-linux
Pinning the resolver to v1 was done in 5abff3753a ("Explicit set
workspace.resolver ...") in order to suppress warnings. Since there is
no specific reason not to use the new resolver and since it fixes
issues, change to `resolver = "2"` everywhere except library and
submodules.
Promote Mac Catalyst targets to Tier 2, and ship with rustup
Promote the Mac Catalyst targets `x86_64-apple-ios-macabi` and `aarch64-apple-ios-macabi` to Tier 2, as per [the MCP](https://github.com/rust-lang/compiler-team/issues/761) (see that for motivation and details).
These targets are now also distributed with rustup, although without the sanitizer runtime, as that currently has trouble building, see https://github.com/rust-lang/rust/issues/129069.
The current cross-compilation toolchain for the LoongArch64 target
consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils
2.40 has known issues that in broken binaries without any error reports:
- https://github.com/rust-lang/rust/issues/121289
- https://github.com/cross-rs/cross/issues/1538
This patch upgrades the cross-compilation toolchain for the LoongArch64 target
to resolve these issues.
- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42
The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36
distribution, and no issues have been identified.
Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option.
Use static linking to avoid a new runtime dependency. Add an llvm.libzstd bootstrap option for LLVM
with zstd. Set it off by default except for the dist builder. Handle llvm-config --system-libs output
that contains static libraries.
The default repository server setting has changed on Fuchsia (default is
newly "false"). Now, in order to start the repository server, the config
`repository.server.enabled` must be set to true.
Since the `rfl` CI job has not had almost any issue for some weeks,
it is a good time to try to increase a bit the scope of what it tests.
The kernel does not use any particular `rustdoc` unstable issue (apart
from the doctests ones) so far, so in principle it should not introduce
extra issues here, and may be a good extra test case for Rust.
In addition, it may help to test new unstable features in the future.
In the worst case, we can revert it.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
We were already generating the doctests, which should already catch most
issues with our hack around `--test-builder` and `--no-run`.
However, we were not building the result of that transformation, thus
build it for completeness and to ensure the hack may not have produced
something completely broken.
In the worst case, we can revert it.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
CI: move RFL job forward to v6.11-rc1
The tag has been released today, and since the original hash we had in the Rust CI (which was ~v6.10-rc1), we have accumulated a fair amount of changes and new code.
In particular, v6.11-rc1 is the first Linux tag where the kernel is supporting an actual minimum Rust version (1.78.0), rather than a single version.
---
Let's try to do the move independently first.
r? ``@Kobzol``
try-job: x86_64-rust-for-linux
The tag has been released today, and since the original hash we had in
the Rust CI (which was ~v6.10-rc1), we have accumulated a fair amount
of changes and new code.
In particular, v6.11-rc1 is the first Linux tag where the kernel is
supporting an actual minimum Rust version (1.78.0), rather than a
single version.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
