ci update freebsd version proposal, freebsd 12 being eol
raising to the lowest still active supported freebsd version.
From 13.1 (already eol too), freebsd introduces a cpu affinity layer
with linux. It also introduces a api compatible copy_file_range which
can be used like its linux's counterpart.
The former is essential to build https://github.com/rust-lang/rust/pull/120589, therefore breaks the backward
compatibility with the previous FreeBSD releases.
Blocked on https://github.com/rust-lang/rust/issues/130465
[A recent commit in LLVM](ab930ee7ca) modified the JSON output of LLVM. The LLVM change renamed "Notes" to "NoteSections" and inserted a new "Notes" key nested under each "NoteSection".
This change shores up exceptions around reading the JSON output of llvm-readelf and reads from "NoteSections" instead of the non-existent "Notes".
raising to the lowest still active supported freebsd version.
From 13.1 (already eol too), freebsd introduces a cpu affinity layer
with linux. It also introduces a api compatible copy_file_range which
can be used like its linux's counterpart.
The former is essential to build #120589, therefore breaks the backward
compatibility with the previous FreeBSD releases.
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
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
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.
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>
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>
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
Many tests use stdout and stderr to validate whether the test emitted
the correct output. Because fuchsia-test-runner.py was sending all
logs, including test output, to stdout, tests could not validate
output properly.
This change removes the runner logs from stdout and stderr entirely
with the exception of output from the test. All runner logs are still
available in the "log" file.
Fixed: https://fxbug.dev/351356417
This synchronizes the fuchsia test running code with the clang test
runner. This brings with it:
* Improved logging
* Uses the fuchsia image from the SDK version
* Caches the product bundle across test runs
* Strips the binaries to reduce the data sent to the emulator
Update fuchsia commit, and SDK to 21.20240610.2.1
This includes a fix to the race when publishing multiple packages at the same time.
try-job: x86_64-gnu-integration
This commit fixes several issues in the fuchsia-test-runner.py script:
1. Migrate from `pm` to `ffx` for package management, as `pm` is now
deprecated. Furthermore, the `pm` calls used in this script no longer
work at Fuchsia's HEAD. This is the largest change in this commit, and
impacts all steps around repository management (creation and
registration of the repo, as well as package publishing).
2. Allow for `libtest` to be either statically or dynamically linked.
The script assumed it was dynamically linked, but the current Rust
behavior at HEAD is to statically link it.
3. Minor cleanup to use `ffx --machine json` rather than string parsing.
4. Minor cleanup to the docs around the script.
Bump Fuchsia versions
This updates the Fuchsia commit used in `auto - x86_64-gnu-integration` CI bot to use the Rust commit 703dc9ce64. This should help improve the coverage of this builder.
It also updates the SDK version to F20.20240412.3.1, and the Fuchsia Clang version to c777c011a709dffd4fa5e79cad7947b7c3405d02.
r? ``@tmandry``
This updates the Fuchsia commit used in `auto - x86_64-gnu-integration`
CI bot to use the Rust commit 703dc9ce64.
This should help improve the coverage of this builder.
It also updates the SDK version to F20.20240412.3.1, and the Fuchsia Clang
version to c777c011a709dffd4fa5e79cad7947b7c3405d02.
