| Age | Commit message (Collapse) | Author | Lines |
|---|
|
For the ones that explicitly picks which test suite to run.
|
|
Fix host code appearing in Wasm binaries
This is a direct fix for issue [132802](https://github.com/rust-lang/rust/issues/132802).
Followed the outline as follows:
> * give a hard error in bootstrap when using gcc to compile for wasm
> * change our CI to use clang instead of gcc
> * add a test that compiling a sample program for wasm32-unknown doesn't give any linker warnings
The `test-various` ci job was also changed.
try-job: test-various
try-job: dist-various-1
try-job: dist-various-2
try-job: x86_64-msvc-1
|
|
This updates the wasi-sdk used in CI to build release binaries and run
CI with. No major motivation beyond keeping things up-to-date and
following the development of wasi-sdk.
|
|
|
|
|
|
|
|
Added sanity check to bootstrap to hard error on wasm builds without
clang, and changed distribution image `dist-various-2` to use clang to
build for official targets.
|
|
- Update r-efi to 5.2.0
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Bump to the latest wasi-sdk-25 release which brings in various wasi-libc
updates as well as LLVM 19 as the version used to compile wasi-libc.
|
|
|
|
|
|
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 previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
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.
|
|
|
|
|
|
This commit updates how the WASI targets are configured with their
toolchain. Long ago a `config.toml` option of `wasi-root` was added to
enable building with the WASI files produced by wasi-libc. Additionally
for CI testing and release building the Rust toolchain has been using a
hard-coded commit of wasi-libc which is bundled with the release of the
`wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is
the go-to solution for compiling/linking WASI code and contains the
more-or-less official releases of wasi-libc. This commit migrates CI to
using wasi-sdk releases and additionally updates `bootstrap` to
recognize when this is configured. This means that with `$WASI_SDK_PATH`
configured there's no further configuration necessary to get a working
build. Notably this also works better for the new targets of WASI as
well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the
wasi-sdk release now has libraries for all targets bundled within it.
|
|
|
|
This is implemented with the freshly-released Wasmtime 19 and should
prevent beta breakage from wasm tests that was observed and fixed
in #122640 again.
|
|
Drop testing of `wasm32-unknown-unknown` and instead only test a WASI
target which enables more debugging utilities such as printing.
|
|
|
|
|
|
|
|
|
|
CI: build CMake 3.20 to support LLVM 17
LLVM 17 will require CMake at least 3.20, so we have to go back to building our own CMake on the Linux x64 dist builder.
r? `@nikic`
|
|
|
|
|
|
|
|
|
|
rust-lang/cargo#10910 starts emitting warning if resolver is not set
for 2021 edition package. We want to surpress the warning for now.
|
|
|
|
Use CI LLVM in `test-various` builder
It was disabled because it needs `lld`, but since #104748 was merged it is no longer needed.
This will speed this test, since it no longer needs to build LLVM.
|
|
|
|
It was disabled because it needs lld, but since 104748 was merged it is
no longer needed.
|
|
|
|
This extends the existing test for x86_64-unknown-uefi to test the
other two UEFI targets as well.
|
|
This syncs it with how the UEFI targets are built in dist-various-2.
|
|
The UEFI targets don't have std support yet, so the normal tests don't
work. However, we can compile a simple no-std program and run it under
QEMU to at least check that the target compiles, links, and runs.
Tested locally with: src/ci/docker/run.sh test-various
|
|
See comment added for details on the test builder restriction. This is primarily
intended for macOS CI, but is likely to be a slight win on other builders too.
|
|
Since our musl targets link to a version of musl we build and bundle
with the targets, if users need to debug into musl or generate
backtraces which contain parts of the musl library, they will be unable
to do so unless we enable and ship the debug info.
This patch changes our dist builds so they enabled debug info when
building musl. This patch also includes a fix for CFI detection in
musl's `configure` script which has been posted upstream[1].
The net effect of this is that we now ship debug info for musl in those
targets. This adds ~90kb to those artifacts but running `strip` on
binaries produced removes all of that. For a "hello world" Rust binary
on x86_64, the numbers are:
| | debug | release | release + strip |
| - | - | - | - |
| without musl debuginfo | 507kb | 495kb | 410kb |
| with musl debuginfo | 595kb | 584kb | 410kb |
Once stripped, the final binaries are the same size (down to the byte).
[1]: https://www.openwall.com/lists/musl/2021/10/21/2
|
|
|
|
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
|
|
The test command-setgroups.rs is adjusted to skip on musl, where
`sysconf(_SC_NGROUPS_MAX)` always returns a dummy value of 32,
even though the actual value is 65536. I'm not sure why this becomes
relevant only now though, as this was apparently the case since
kernel 2.6.4.
|
|
|
|
Trying to fix a problem in CI. Maybe some version of Docker is not
passing '' args correctly?
|
|
|
|
Windows CI builds already install ninja. Install it in all the
Docker-based builds as well.
|
|
- expand yaml anchors
- don't use --stage 2 for dist; that's already the default
|
|
|
|
We need to add runners designed for an aarch64 host system, and it'd be
nice to return an error message if someone tries to run an image
designed for an host architecture in another one.
To start the work on this, this commit moves all the existing builders
in the host-x86_64 directory, and changes the run.sh script to look up
the image in the correct directory based on the host architecture.
|
