| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(cherry picked from commit 0d94e6bac90a804041cf1847e034001b7517e29a)
|
|
(cherry picked from commit 2f6307d1cca53c153bddee83f4331fe979c61fe4)
|
|
(cherry picked from commit 7358429c00bb874420866d5f78b7166e79ad9f1f)
|
|
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
|
|
|
|
move it where it's used, and name it like the other scripts
|
|
Link: https://github.com/rust-lang/rust/pull/129416
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Switch to using the v2 resolver in most workspaces
Pinning the resolver to v1 was done in 5abff3753a7c ("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 5abff3753a7c ("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.
|
|
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.
|
|
|
|
Build libzstd from source because the EPEL package is built without fPIC.
|
|
|
|
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>
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
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
|
|
This includes changes to unblock merging #126024.
|
|
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.
|
|
) brew install python@3.10
) python3.10 -m venv /tmp/myenv
) source /tmp/myenv/bin/activate
) pip install pip-tools
) /tmp/myenv/bin/pip-compile --allow-unsafe --generate-hashes reuse-requirements.in
|
|
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.
|
|
Improve error when a compiler/library build fails in `checktools.sh`
Suggested by ``@RalfJung`` [here](https://github.com/rust-lang/rust/issues/127869#issuecomment-2235829643).
`x86_64-gnu-tools` should take ~45 minutes, let's see if this doesn't regress it.
r? ``@onur-ozkan``
|
|
|
|
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.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
`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>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
) Updated requirements file
) Ran `reuse convert-dep5` to switch to new file format
|
|
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
|
|
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
|
|
Applied formatting suggestions from isort and black via pylsp.
|
|
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 should make it possible to switch running `auto` and `try` builds from `rust-lang-ci` to `rust-lang`.
|
|
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
|
