| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Adds the --enable-profiler flag to the RUST_CONFIGURE_ARGS for armhf distribution for Linux. This enables running coverage for tests
|
|
|
|
debug info there.
Fixes #130063.
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Update x86_64-linux host compiler to LLVM 19 rc 3
|
|
|
|
|
|
move it where it's used, and name it like the other scripts
|
|
|
|
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.
|
|
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 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``
|
|
|
|
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
|
|
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.
|
|
|
|
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
|
|
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
|
|
`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
|
