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>
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
Use reuse tool 4.0
This change upgrades us to reuse-tool 4.0.3, which has a new TOML format configuration instead of the old `.reuse/dep5` Debian-style file.
* Updated requirements file to install reuse-4.0.3
* Ran `reuse convert-dep5` to switch to new file format
* Switched over to `override` so the `REUSE.toml` file takes precedence over whatever random Copyright strings `reuse` finds in the source tree.
Should fix https://github.com/rust-lang/rust/issues/127361
Update wasi-sdk in CI to latest release
This commit updates the `wasi-sdk` download used by the `wasm32-wasi*` targets. The motivation for this commit is generally just "keep things up to date" and is not intended to cause any issues or differences from before, just a routine update.
Fix git safe-directory path for docker images
This fixes the path for configuring the git safe.directory setting inside docker images. AFAIK, `~/gitconfig` without a dot is not something that git uses ([ref](https://git-scm.com/docs/git-config)). This was needed in my environment to avoid the ` fatal: detected dubious ownership in repository at '/checkout'` error. For context, this was added in #99967.
This commit updates the `wasi-sdk` download used by the `wasm32-wasi*`
targets. The motivation for this commit is generally just "keep things
up to date" and is not intended to cause any issues or differences from
before, just a routine update.
remove `debug-logging` default from tools profile
`debug-logging` conflicts with `download-rustc` option, and doesn't really make sense to enable it for a profile that is used for tool development.
`debug-logging` conflicts with `download-rustc` option, and doesn't really
make sense to enable it for a profile that is used for tool development.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Commonize `uname -m` results for `aarch64` in docker runner
`uname -m` on Linux reports `aarch64`, but on MacOS reports `arm64`. Commonize this to `aarch64`.
With this fix, it is now possible to run aarch64 CI docker images on Arm MacOS.
`uname -m` on Linux reports `aarch64`, but on MacOS reports `arm64`.
Commonize this to `aarch64`.
With this fix, it is now possible to run aarch64 CI docker images on Arm
MacOS.
Promote the `wasm32-wasip2` target to Tier 2
This commit promotes the `wasm32-wasip2` Rust target to tier 2 as proposed in rust-lang/compiler-team#760. There are two major changes in this PR:
1. The `dist-various-2` container, which already produces the other WASI targets, now has an extra target added for `wasm32-wasip2`.
2. A new `wasm-component-ld` binary is added to all host toolchains when LLD is enabled. This is the linker used for the `wasm32-wasip2` target.
This new linker is added for all host toolchains to ensure that all host toolchains can produce the `wasm32-wasip2` target. This is similar to how `rust-lld` was originally included for all host toolchains to be able to produce WebAssembly output when the targets were first added. The new linker is developed [here][wasm-component-ld] and is pulled in via a crates.io-based dependency to the tree here.
[wasm-component-ld]: https://github.com/bytecodealliance/wasm-component-ld
use "bootstrap" instead of "rustbuild" in comments and docs
Let's stick with the single name "bootstrap" to refer to the bootstrap project to avoid confusion. This should make it clearer, especially for new contributors.
Update dist-riscv64-linux to binutils 2.40
binutils 2.40 is required by LLVM 19, as older versions do not know about the zmmul extension.
I've had to backport some patches to glibc and gcc as well, as they don't build with binutils 2.40. Alternatively, we could also switch to glibc 2.35 and gcc 10 (I think). I figured we'd want to avoid the glibc version change, but if that's fine for riscv I can go with that instead.
r? `````@cuviper`````
try-job: dist-riscv64-linux
binutils 2.40 is required by LLVM 19, as older versions do not
know about the zmmull extension.
I've had to backport some patches to glibc and gcc as well,
as they don't build with binutils 2.40. Alternatively, we could
also switch to glibc 2.35 and gcc 12 (I think). I figured we'd
want to avoid the glibc version change, but if that's fine for
riscv I can go with that instead.
Fix local download of Docker caches from CI
https://github.com/rust-lang/rust/pull/127312 broke local downloads of Docker caches from CI, when you wanted to build a Docker image locally. This PR fixes that.
r? `@nikic`
(Can you please check if the cache works for you with this PR?)
Fixup failing fuchsia tests
The Fuchsia platform passes all tests with these changes. Two tests are ignored because they rely on Fuchsia not returning a status code upon a process aborting. See #102032 and #58590 for more details on that topic.
Many formatting changes are also included in this PR.
r? tmandry
r? erickt
This commit promotes the `wasm32-wasip2` Rust target to tier 2 as
proposed in rust-lang/compiler-team#760. There are two major changes in
this PR:
1. The `dist-various-2` container, which already produces the other WASI
targets, now has an extra target added for `wasm32-wasip2`.
2. A new `wasm-component-ld` binary is added to all host toolchains when
LLD is enabled. This is the linker used for the `wasm32-wasip2` target.
This new linker is added for all host toolchains to ensure that all host
toolchains can produce the `wasm32-wasip2` target. This is similar to
how `rust-lld` was originally included for all host toolchains to be
able to produce WebAssembly output when the targets were first added.
The new linker is developed [here][wasm-component-ld] and is pulled in
via a crates.io-based dependency to the tree here.
[wasm-component-ld]: https://github.com/bytecodealliance/wasm-component-ld
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
The CDN has been down for a few hours. Switch to an alternative for the
time being so we can unblock CI.
It appears that the CDN is quite a bit faster, so we will likely want to
switch back when available.
Fix x86_64 code being produced for bare-metal LoongArch targets' `compiler_builtins`
Formerly the `loongarch*-*-none*` targets were added to the `dist-various-2` CI job, but no corresponding toolchain was added along with them. This meant the `compiler_builtins` for the targets were built with the host toolchain.
As the other `dist-various` toolchains are mostly pre-built so far, to avoid burdening them with crosstool-ng builds, simply move the two bare-metal LoongArch targets to the `dist-loongarch64-linux` job which has a ready-to-use LoongArch toolchain. With the proper CFLAGS applied it is possible to build artifacts suitable for bare-metal. I verified that the `compiler_builtins` objects are now correctly produced regarding architecture and ABI, with the changes here applied.
Fixes#125908.
cc ``@heiher``
try-job: dist-loongarch64-linux
try-job: dist-various-2
Formerly the `loongarch*-*-none*` targets were added to the
`dist-various-2` CI job, but no corresponding toolchain was added along
with them. This meant the `compiler_builtins` for the targets were built
with the host toolchain.
As the other `dist-various` toolchains are mostly pre-built so far, to
avoid burdening them with crosstool-ng builds, simply move the two
bare-metal LoongArch targets to the `dist-loongarch64-linux` job which
has a ready-to-use LoongArch toolchain. With the proper CFLAGS applied
it is possible to build artifacts suitable for bare-metal. I verified
that the `compiler_builtins` objects are now correctly produced
regarding architecture and ABI, with the changes here applied.
Fixes#125908.
cc @heiher
try-job: dist-loongarch64-linux
try-job: dist-various-2
Rename fuchsia builder and bump Fuchsia
This PR renames the fuchsia builder as requested in https://github.com/rust-lang/rustc-dev-guide/pull/1989#pullrequestreview-2148682346 and bumps Fuchsia.
This includes the quality-of-life improvements for developers in https://fxrev.dev/1061894. It also removes the wasm target, which should speed up the build a little.
The new name of the builder is `x86_64-fuchsia` because I think `x86_64-gnu-fuchsia` would be confusing and put too much emphasis on the host target. (In terms of triples, we are targeting `x86_64-unknown-fuchsia` from `x86_64-unknown-linux-gnu`.) Someone on the infra team should weigh in here.
After this lands, we should update the docs in the rustc-dev-guide again.
cc `@lqd`
r? t-infra
try-job: x86_64-fuchsia
Rollup of 11 pull requests
Successful merges:
- #123714 (Add test for fn pointer duplication.)
- #124091 (Update AST validation module docs)
- #127015 (Switch back `non_local_definitions` lint to allow-by-default)
- #127016 (docs: check if the disambiguator matches its suffix)
- #127029 (Fix Markdown tables in platform-support.md)
- #127032 (Enable const casting for `f16` and `f128`)
- #127055 (Mark Hasher::finish as #[must_use])
- #127068 (Stall computing instance for drop shim until it has no unsubstituted const params)
- #127070 (add () to the marker_impls macro for ConstParamTy)
- #127071 (Remove (deprecated & unstable) {to,from}_bits pointer methods)
- #127078 (Enable full tools and profiler for LoongArch Linux targets)
r? `@ghost`
`@rustbot` modify labels: rollup
