* Remove some yanked crates from `Cargo.lock`
This commit fixes some warnings that are cropping up during publishing
about yanked crates being in our `Cargo.lock`.
* Remove an unneeded vet `imports.lock` entry
I was curious how `deserialize` compared with `deserialize_file`. There was
already a `bench_deserialize_module` so I expanded it to support `deserialize`.
Some results:
```
Benchmarking deserialize/deserialize/wasi.wasm
Benchmarking deserialize/deserialize/wasi.wasm: Warming up for 3.0000 s
Benchmarking deserialize/deserialize/wasi.wasm: Collecting 100 samples in estimated 5.4918 s (50k iterations)
Benchmarking deserialize/deserialize/wasi.wasm: Analyzing
deserialize/deserialize/wasi.wasm
time: [107.44 µs 108.00 µs 108.56 µs]
Found 9 outliers among 100 measurements (9.00%)
6 (6.00%) high mild
3 (3.00%) high severe
Benchmarking deserialize/deserialize_file/wasi.wasm
Benchmarking deserialize/deserialize_file/wasi.wasm: Warming up for 3.0000 s
Benchmarking deserialize/deserialize_file/wasi.wasm: Collecting 100 samples in estimated 5.0337 s (56k iterations)
Benchmarking deserialize/deserialize_file/wasi.wasm: Analyzing
deserialize/deserialize_file/wasi.wasm
time: [89.572 µs 89.705 µs 89.872 µs]
Found 14 outliers among 100 measurements (14.00%)
9 (9.00%) high mild
5 (5.00%) high severe
```
* Update release date of Wasmtime 9.0.0
* Update release date
---------
Co-authored-by: Wasmtime Publish <wasmtime-publish@users.noreply.github.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* riscv64: Support vector instruction masking
* riscv64: Add `vmerge` instructions
* riscv64: Implement `insertlane`
* riscv64: Fix encoding of `vmv` instructions
Some of these carry their source in vs2
* riscv64: Fix formatting of mask register
Remove the space between , and the register. This
is inline with the rest of our formatting.
* riscv64: Restrict `insertlane` to vector types that fit in a single register
* wasmtime: Enable more RISC-V SIMD tests
* riscv64: Use inline format syntax for printing vector instructions
* riscv64: Add vector mask note
This fuzz target was accidentally broken by #6378 and I forgot to update
this fuzz target. Namely all the generated types now need names to
satisfy possible restrictions depending on the structure. For simplicity
everything is given a name to avoid having to special case some vs
others which isn't the purpose of this fuzz target.
this is causing a link error because pulldown_cmark is available both in
the rust_wasi_markdown_parser deps directory and, now, in the root of
the project as well.
Many of the tests for lowering features use `extractor`s I think since
when they were added that was the only option. Nowadays a `pure
constructor` with `if-let` feels more natural for this, so this commit
updates all existing extractors used to test features to use a `pure
constructor` instead. This additionally updates the names to match the
cranelift codegen setting name to ensure that a consistent name is used.
This is an unnecessary restriction: applications shouldn't be relying on
any ordering of preview1 fds, besides that other files are not found in
the stdio range.
This behavior changed with the introduction of the component adapter,
but I am making a separate PR to edit the test rather than make it part
of #6391.
Currently all the jobs in GitHub Actions are configured to cancel the
entire run if any of them fail. This is similar to `fail-fast: true` but
that can't be used because the jobs aren't all part of the same matrix.
The original goal for this was to save CI time on the merge queue where
if something failed it should get out of the merge queue quickly instead
of waiting for all other jobs to succeed and then report the one quick
failure.
This seems to run into an issue, though, where if a Windows builder
fails then running cancellation will instead mark the Windows builder as
cancelled instead of failed. This can be confusing for test failures
because nothing looks obvious and each log needs to be manually pored
over.
To help address this the commit here disables auto-cancellation of the
"test" matrix of jobs, re-enabling `fail-fast: true` at the same time.
This way test if a test job fails it won't actually cancel everything
else so everything else will run to completion, but given that tests are
typically the longest part of the build that's hopefully ok.
This change intends to add a new lowering for `MachInst::LoadExtName`
(the pseudo-instruction behind CLIF's `func_addr` and `symbol_addr`)
that uses RIP-relative addressing when the name is local to the module
(`colocated`). The existing behavior is retained, which currently loads
from the global offset table when the `is_pic` flag is set (a
`X86GOTPCRel4` relocation) or loads a relocated immediate (an `Abs8`
relocation). After this change, a `lea` instruction will calculate a
RIP-relative address if the name in question is marked with CLIF's
`colocated` flag.
Why is this necessary? Though some users of Cranelift, like
`cranelift-jit`, understand how to relocate the existing `Abs8`
relocations (see [`CompiledBlob::perform_relocations`]), Wasmtime does
not. Though technically Wasmtime does apply relocations (see
[`CodeMemory::apply_relocations`]), these are only for libcalls.
Wasmtime will attempt to resolve module-local functions, the ones
targeted by `func_addr`, via some internal relocation patching in
[`ModuleTextBuilder::append_func`]. When it realizes it cannot patch one
of these functions, it panics because [`LabelUse::from_reloc`] only
understands the `X86CallPCRel4` relocation. This prevents the use of
`func_addr` when translating Wasm code. Since no current Wasmtime
translation uses `func_addr` directly, this change is not technically
required, but it does feel like the right option to add, normalizing
`func_addr`'s behavior for local functions to `MachInst::CallKnown`'s
behavior and making it more useful for other Cranelift users in the
future.
[`CompiledBlob::perform_relocations`]: 752c7ea4dd/cranelift/jit/src/compiled_blob.rs (L48)
[`CodeMemory::apply_relocations`]: 752c7ea4dd/crates/jit/src/code_memory.rs (L269)
[`ModuleTextBuilder::append_func`]: 752c7ea4dd/crates/cranelift-shared/src/obj.rs (L145)
[`LabelUse::from_reloc`]: 752c7ea4dd/cranelift/codegen/src/isa/x64/inst/mod.rs (L2759)
* wasi-tests and wasi-http-tests no longer have their own workspace
* wasi-tests: fix warnings
* rewrite the test-programs build.rs to generate {package}_modules.rs and _components.rs
The style is cribbed from preview2-prototying repo, but I ended up
refactoring it a bit.
* better escaping should help with windows?
* long form cap-std-sync and tokio test suites
* convert wasi-http test
* fixes, comments
* apply cargo fmt to whole workspace
* bump test-programs and wasi-http-tests to all use common dependency versions
wit-bindgen 0.6.0 and wit-component 0.7.4
* add new audits
* cargo vet prune
* package and supply chain updates to fix vulnerabilities
h2 upgraded from 0.3.16 -> 0.3.19 to fix vulnerability
tempfile upgraded from 0.3.3 -> 0.3.5 to eliminate dep on vulnerable
remove_dir_all
* deny: temporarily allow duplicate wasm-encoder, wasmparser, wit-parser
prtest:full
* convert more dependencies to { workspace = true }
Alex asked me to do thsi for wit-component and wit-bindgen, and I found
a few more (cfg-if, tempfile, filecheck, anyhow...
I also reorganized the workspace dependencies section to make the ones
our team maintains more clearly separated from our external
dependencies.
* test-programs build: ensure that the user writes a #[test] for each module, component
* fix build of wasi-tests on windows
* misspelled macos
* mark wasi-tests crate test=false so we dont try building it natively...
* mark wasi-http-tests test=false as well
* try getting the cargo keys right
* just exclude wasi-tests and wasi-http-tests in run-tests.sh
* interesting paths fails on windows
* misspelling so nice i did it twice
* new cargo deny exception: ignore all of wit-bindgen's dependencies
* auto-import wildcard vets
* x64: Update i64x2 `sshr` implementation
The previous implementation fell back to a scalar implementation by
extracting lanes and re-inserting them. These operations are
significantly more complicated without SSE 4.1, however. Comparing
against LLVM's lowerings, as well, it looks like a different strategy is
used which avoids extracting and inserting lanes. This commit updates to
follow the strategy matched by LLVM's lowerings which additionally has
the benefit of providing a non-SSE4.1 implementation.
* Update an outdated comment
* Update wasm-tools crates to latest versions.
This included stubbing out unimplemented GC-related things and
updating coredump generation to include the coredump spec changes.
* cargo vet
* address review comments