NetBSD CI is disabled because it is not yet supported in
zig-bootstrap. Once NetBSD has proper zig-bootstrap support, it can be
re-enabled.
Windows is not solved here yet; will be pushing a separate commit for
that.
This commit reverts 6d37ae95edc06f15e4e77f64e8e637dd5d269183 and
8f8294a809f9d975735377e7bfcc2c47ccfc4cb7. I don't know why they caused a
failure but that investigation can happen while the CI is green.
This supports the case when it is known that LLVM, Clang, LLD were built
with Clang (or `zig c++`). This commit updates the Linux CI script to
pass this since we build using a zig tarball.
This extra message was intended to help contributors by clarifying
what to do when they hit a `zig fmt` failure, but now AST errors are
also emitted here and the message may actually introduce confusion.
Remove it for now.
This breaking change disambiguates between overriding the lib dir when
performing an installation with the Zig Build System, and overriding the
lib dir that the Zig installation itself uses.
Since v0.23 release of Wasmtime, if we want to iterate a directory
Y then directory Y needed to have been granted `fd_readdir` right.
However, it is now also required for directory X to carry `fd_readdir`
right, and so on, up-chain all the way until we reach the preopen
(which possesses all rights by default).
This caused problems for us since our libstd implementation is more
fine-grained and allowed for parent dirs not to carry the right while
allow for iterating on its children. My proposal here is to always
grant `fd_readdir` right as part of
`std.fs.Dir.OpenDirOptions.access_sub_paths`. This seems to be the
approach taken by Rust also, plus we should be justified to take this
approach since WASI is experimental and snapshot1 will be discontinued
eventually and replaced with a new approach to access management
that will require a complete rewrite of our libstd anyhow.
On CI, we have been running into OOM issues when running the test
suite on Windows for quite some time.
Unfortunately, we are very close to having the same issues on Linux
as well. Some additional comptime work immediately makes these builds
fail as well.
Add a new `test-toolchain` step, that tests everything except `std.*`
and documentation.
On CI, call `test-toolchain`, `test-std` and `docs` separately
instead of the `test` big hammer that emcompasses all of them.
Change the special case we made for Windows to the same code as other
platforms.
This is a stopgap measure that stage2 will eventually make useless.
Until then, it gives us some headroom.
Change `linux_script` by the way to only output the log of failing
steps. This shrinks the Linux CI log from a bazilion lines down to
something more humanely manageable.
I got this error when re-running the cmake line setting
-DZIG_EXECUTABLE:
```
ninja: warning: multiple rules generate zig1.o. builds involving
this target will not be correct; continuing anyway
[-w dupbuild=warn]
```
But it works fine with make.
* no longer depend on apt.llvm.org, instead we rely on a zig-bootstrap
tarball with pre-built Zig, LLVM, LLD, and Clang. Similar to the
Windows Dev Kit but for Linux. This also makes the script no longer
depend on Docker, libxml2, or GCC.
* remove bash retry logic; it was only needed for flaky apt.llvm.org
and isn't needed for the other resources we download.
* build and upload the experimental std lib automatically generated
docs. langref.html is moved to docs/langref.html because the std lib
docs are in docs/std/.
* the superfluous "zig" directory in $prefix/lib/zig/std/std.zig is
removed from the tarball.
* update_download_page makes a commit in the www.ziglang.org repository
updating data/releases.json so that repository can manage deploys.
git describe is used for version string creation, but it had to be
reverted in commit 69da6ba because it was broken in CI builds.
Azure Pipelines and Drone perform shallow clones by default.
This change reconfigures them to fetch history and tags. It adds tens of
seconds, which is negligible compared to overall build and test time.
Related: #6466, #6509, #7601
The version we were using in CI is now getting quite old, and we
want to make sure that the code we produce is compatible with
current versions of Wasmtime.
