Update @bjorn3/browser_wasi_shim to version 0.4.2. This release includes
a limited polyfill for `poll_oneoff`, which is necessary for the
`pthread_cond` test to pass in the browser.
https://github.com/bjorn3/browser_wasi_shim/pull/88

The `pthread_cond` test uses `nanosleep` which eventually calls
`poll_oneoff` but `@bjorn3/browser_wasi_shim` does not implement it. So
we skip the test for now, but we will revisit it later once
https://github.com/bjorn3/browser_wasi_shim/pull/88 is merged.

We are heavily using wasi-libc + wasip1-threads on browsers. Since
wasi-libc uses `memory.atomic.wait32` to implement futex, and the usage
of `memory.atomic.wait32` on the main thread is prohibited on browsers,
we currently need to write code carefully not to reach the instruction.

Emscripten addresses this limitation by [employing a busy-wait on the
main
thread](https://github.com/emscripten-core/emscripten/blob/058a9fff/system/lib/pthread/emscripten_futex_wait.c#L111-L150)
as a workaround. Rust has [always employs busywait regardless of the
current thread is
main](https://github.com/rust-lang/rust/blob/a47555110cf09b3ed59811d9b02235443e76a595/library/std/src/sys/alloc/wasm.rs#L75-L144).
This approach, while effective for browsers, introduces unnecessary
overhead in environments where memory.atomic.wait32 is permitted.

This change provides a similar solution by introducing an opt-in
busy-wait mode for futexes. By making this an optional feature, we avoid
imposing the overhead of busy-waiting in non-browser environments while
ensuring compatibility with browser-based restrictions.

```c
#include <wasi/libc-busywait.h>

/// Enable busywait in futex on current thread.
void __wasilibc_enable_futex_busywait_on_current_thread(void);
```

This change slightly adds some runtime overheads in futex to check if we
should use busywait, but it can be optimized away as long as
`__wasilibc_enable_futex_busywait_on_current_thread` is not used by user
program and LTO is enabled.

https://github.com/WebAssembly/wasi-libc/pull/563#discussion_r1940291020

This PR updates ADAPTER_URL to reference the latest release version
(versions 29.0.1)

This PR updates WASM_TOOLS_URL to reference the latest released version
(version 1.224.0)

This PR updates WASMTIME_URL to reference the latest release version
(29.0.1)

This PR updates LIBRT_URL to reference the latest release version
(wasi-sdk-25).

This commit adds a browser test harness to run the tests in the browser.

## Motivation

We are heavily using wasi-libc on browsers but we don't have any test
for the case in wasi-libc. In theory, there should be no behavioral
difference between wasmtime and browsers (as long as WASI
implementations are correct) but browsers have their own limitations in
their Wasm engines. For example, memory.atomic.wait32 is not permitted
on the main thread.

We are working on adding some mitigation for such browser-specific
issues (https://github.com/WebAssembly/wasi-libc/pull/562) and this test
harness will help to validate the fix.

This change enables the pthread-related tests in the libc-test suite.
The tests are enabled only for the `wasm32-wasip1-threads` target, which
is the only target that supports threads at the moment.

The following pthread tests are still disabled:
- pthread_cancel-points.c
- pthread_cancel.c
- pthread_robust.c

This is a preparative change for
https://github.com/swiftwasm/swift/issues/5598

Follow-up to 2b853ff0

The wrong shebang caused `&>` to be interpreted as a background job

This change represents a rather large re-design in how `wasi-libc`
builds and runs its tests. Initially, #346 retrieved the `libc-test`
repository and built a subset of those tests to give us some amount of
test coverage. Later, because there was no way to add custom C tests,
#522 added a `smoke` directory which allowed this. But (a) each of these
test suites was built and run separately and (b) it was unclear how to
add more tests flexibly--some tests should only run on `*p2` targets or
`*-threads` targets, e.g.

This change reworks all of this so that all tests are built the same
way, in the same place. For downloaded tests like those from
`libc-test`, I chose to add "stub tests" that `#include` the original
version. This not only keeps all enabled tests in one place, it also
allows us to add "directives," C comments that the `Makefile` uses to
filter out tests for certain targets or add special compile, link or run
flags. These rudimentary scripts, along with other Bash logic I moved
out of the Makefile now live in the `scripts` directory.

Finally, all of this is explained more clearly in an updated
`README.md`. The hope with documenting this a bit better is that it
would be easier for drive-by contributors to be able to either dump in
new C tests for regressions they may find or enable more libc-tests. As
of my current count, we only enable 40/75 of libc-test's functional
tests, 0/228 math tests, 0/69 regression tests, and 0/79 API tests.
Though many of these may not apply to WASI programs, it would be nice to
explore how many more of these tests can be enabled to increase
wasi-libc's test coverage. This change should explain how to do that
and, with directives, make it possible to condition how the tests
compile and run.

This updates:
- `wasi-sdk` to v24
- Wasmtime to v26.0.1
- `wasm-tools` to v1.220.0

Close https://github.com/WebAssembly/wasi-libc/issues/520

Add FTS implementation derived from musl-fts with a few modifications.
The compiled fts.o is included in the libc.a archive, and the fts.h
header is installed in the sysroot (`include/fts.h`).

* fts/musl-fts: Add a copy of the musl-fts sources with modifications.
* fts/patches: A set of patches to apply to the musl-fts sources.
* Upstream pull request: https://github.com/void-linux/musl-fts/pull/14
* fts/update-musl-fts.sh: A script to update the musl-fts sources with
the patches applied.
* fts/config.h: A configuration header included by the musl-fts sources.
* test/smoke: Add a test suite for wasi-libc specific features that
libc-test does not cover.

* implement basic TCP/UDP client support

This implements `socket`, `connect`, `recv`, `send`, etc. in terms of
`wasi-sockets` for the `wasm32-wasip2` target.

I've introduced a new public header file: `__wasi_snapshot.h`, which will define
a preprocessor symbol `__wasilibc_use_wasip2` if using the `wasm32-wasip2`
version of the header, in which case we provide features only available for that
target.

Co-authored-by: Dave Bakker <github@davebakker.io>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* fix grammar in __wasi_snapshot.h comment

Co-authored-by: Dan Gohman <dev@sunfishcode.online>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>

---------

Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Co-authored-by: Dave Bakker <github@davebakker.io>
Co-authored-by: Dan Gohman <dev@sunfishcode.online>

* Start renaming preview1 to p1 and preview2 to p2

This is an initial start at renaming the "preview" terminology in WASI
targets to "pX". For example the `wasm32-wasi` target should transition
to `wasm32-wasip1`, `wasm32-wasi-preview2` should transition to
`wasm32-wasip2`, and `wasm32-wasi-threads` should transition to
`wasm32-wasip1-threads`. This commit applies a few renames in the
`Makefile` such as:

* `WASI_SNAPSHOT` is now either "p1" or "p2"
* The default p2 target triple is now `wasm32-wasip2` instead of
  `wasm32-wasi-preview2` (in the hopes that it's early enough to change
  the default).
* Bindings for WASIp2 were renamed from "preview2" terminology to "wasip2".
* The expected-defines files are renamed and the logic of which
  expectation was used has been updated slightly.

With this commit the intention is that non-preview2 defaults do not
change. For example the default build still produces a `wasm32-wasi`
sysroot. If `TARGET_TRIPLE=wasm32-wasip1` is passed, however, then that
sysroot is produced instead. Similarly a `THREAD_MODEL=posix` build
produces a `wasm32-wasi-threads` sysroot target but you can now also
pass `TARGET_TRIPLE=wasm32-wasip1-threads` to rename the sysroot.

My hope is to integrate this into the wasi-sdk repository and build a
dual sysroot for these new targets for a release or two so both are
supported and then in the future the defaults can be switched away from
`wasm32-wasi` to `wasm32-wasip1` as built-by-default.

* Update builds in CI

* Update test workflow

* Fix test for wasm32-wasip1-threads

* Make github actions rules a bit more readable

* make the Makefiles a bit more robust

- Escape "." character in `sed` regex
- Ensure that %.wasm target fails cleanly (i.e. without generating the target file) if `wasm-tools` fails

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* split `component new` rule out of link rule for Preview 2

We now explicitly distinquish between core module files (%.core.wasm) and
component files (%.wasm), which helps avoid the trickery in my previous commit.

In order to test this properly, I needed to update the Wasmtime URL to point to
v17.0.0 instead of dev (which we needed to do anyway), and that in turn required
updating the bindings to use the final WASI 0.2.0 release.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

---------

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

To avoid errors like:

```
Caused by:
    0: import `wasi:cli/environment@0.2.0-rc-2023-12-05` has the wrong type
    1: instance export `get-arguments` has the wrong type
    2: expected func found nothing
make: *** [Makefile:185: /home/runner/work/wasi-libc/wasi-libc/test/build/functional/argv.wasm.err] Error 1
Error: Process completed with exit code 2.
```

Also, bump them to 17.

* add WASI Preview 2 bindings

This adds C bindings generated from the `wasi:cli/imports@0.2.0-rc-2023-12-05`
world, plus a makefile target to regenerate them from the WIT source files.

We'll use these bindings to call Preview 2 host functions when building for the
`wasm32-wasi-preview2` target.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* update to pre-release of `wit-bindgen` 0.17.0

This includes https://github.com/bytecodealliance/wit-bindgen/pull/804 (fix
broken indentation in generated code) and
https://github.com/bytecodealliance/wit-bindgen/pull/805

 (support overriding
world name and adding a suffix to the component type custom section).

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* test all targets; update preview2 expected output files

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* build for `wasm32-wasi-threads` before testing it

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* move generated bindings per review feedback

Since these files aren't part of cloudlibc, no reason to put them under the
cloudlibc directory.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* move preview2.h to wasi directory

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

---------

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Currently, this is identical to the `wasm32-wasi` in all but name.  See #449 for
the next step, which is to incrementally add Preview 2 features,
e.g. `wasi-sockets`.  Per the discussion in that PR, I've split the
`wasi-sysroot/include` directory into per-target directories.  Eventually, we'll
want to build a separate sysroot for each target, but there's currently
uncertainty about how to configure the default sysroot for e.g. clang, so we're
not tackling that yet.

See also #447 for further details.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* test: run a subset of tests from `libc-test`

This change introduces a `test` directory that retrieves the `libc-test`
suite, compiles a subset of the tests using `wasi-libc`, and runs them
with Wasmtime.

* ci: run tests during CI

This change includes some fixups to the filesystem to place Clang's
runtime library for `wasm32-wasi` in the right location. Note that this
CI action is limited to a single OS--Linux.