* Make the Wasmtime CLI use async
This means that interrupting a running Wasm program will now work
correctly, even when the program is blocked on I/O or waiting on a timeout or
some such.
This also involved making `wasi-threads` async-compatible.
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
* rustfmt
* Make `run` command enable the `tokio` feature
* Add a test for CLI, timeouts, and sleeping forever
* Fix warning
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays
This commit introduces the `wasmtime::ArrayRef` type and support for allocating
Wasm GC arrays from the host. This commit does *not* add support for the
`array.new` family of Wasm instructions; guests still cannot allocate Wasm GC
objects yet, but initial support should be pretty straightforward after this
commit lands.
The `ArrayRef` type has everything you expect from other value types in the
`wasmtime` crate:
* A method to get its type or check whether it matches a given type
* An implementation of `WasmTy` so that it can be used with `Func::wrap`-style
APIs
* The ability to upcast it into an `AnyRef` and to do checked downcasts in the
opposite direction
There are, additionally, methods for getting, setting, and enumerating a
`ArrayRef`'s elements.
Similar to how allocating a Wasm GC struct requires a `StructRefPre`, allocating
a Wasm GC array requires an `ArrayRefPre`, and this is motivated by the same
reasons.
* fix some doc tests and add docs for Func::wrap-style APIs
* Add a comment about why we can't user `iter::repeat(elem).take(len)`
* Fix some warnings in no-gc builds
The skeleton unit may contain attributes that don't appear in
the split unit. In particular, this includes DW_AT_ranges and
DW_AT_comp_dir.
Also, set the correct form for the default directory in the
line program. Previously, the different form meant that we emitted
the directory again when a file used it. Copying the DW_AT_comp_dir
attribute is required for use of the default directory to work
successfully.
* Refactor use of `CodeBuilder` on the CLI
This commit refactors `wasmtime run` and `wasmtime compile` to
unconditionally use `CodeBuilder` internally. This will in theory help
out in the future if more debug-related options are added to
`CodeBuilder` for example. This refactoring required some changes to
`CodeBuilder` to be able to support a query about whether the internal
bytes were a component or a module. The text format is now converted to
binary immediately when supplied rather than during the compilation
phase. This in turn required some API changes to make the selection of
supporting the text format a compile-time choice of method rather than a
runtime value.
* Fix compile
* Fix no-cranelift build of CLI
* Add the ability to generate async drop methods for resources.
In the component model, `resource.drop` is a canonical built-in without a proper name. So I invented a custom naming scheme for the component bindgen config. I went with:
`"[drop]{resource-name}"` where `{resource-name}` is the name as defined in WIT. e.g. `"[drop]input-stream"`.
This shouldn't conflict with anything existing in the wild as WIT identifiers are not allowed to contain square brackets.
* Add test for resource_async
* Improve codegen for enums with many cases
This commit improves the compile time of generating bindings for enums
with many cases in them (e.g. 1000+). This is done by optimizing for
enums specifically rather than handling them generically like other
variants which can reduce the amount of code going into rustc to O(1)
instead of O(N) with the number of cases. This in turn can greatly
reduce compile time.
The tradeoff made in this commit is that enums are now required to have
`#[repr(...)]` annotations along with no Rust-level discriminants
specified. This enables the use of a `transmute` to lift a discriminant
into Rust with a simple bounds check. Previously this was one large
`match` statement.
Closes#9081
* Fix some tests
* Add repr tag in fuzzing
* Fix syntax for Rust 1.78
We were using a string, but the DWARF standard specifies that:
"The value of the DW_AT_decl_file attribute corresponds to a file number from
the line number information table...".
Additionally, a typo meant we were overwriting the file attribute with
the value that was meant to be used for a DW_AT_decl_line attribute.
This commit simplifies the selection of an ABI for wasm functions now
that all Cranelift backends implement tail calls. All wasm functions use
the `Tail` calling convention except when the `winch_callable` tunable
is enabled meaning that Winch-generated functions are being called.
This then additionally simplifies the activation of the tail call
proposal. It's not unconditionally active and the same across all
compilers. The Winch compiler is updated to return an error for
unsupported instructions rather than panicking so the embedder API is
suitable for feeding unsupported modules to Winch. This means that tail
calls in Winch behaves similarly to GC in Cranelift or other unsupported
proposals like SIMD in Winch.
This adds support for a newly defined tail-call ABI for s390x
as well as supporting tail calls themselves.
We now use the tail-call ABI by default for Wasmtime, and
enable tail calls by default.
This also allows getting rid of a number of special case
and test exclusions for s390x.
Fixes: https://github.com/bytecodealliance/wasmtime/issues/6530
* Bump MSRV to 1.78.0
This commit updates to use Rust 1.80 in CI as well as updating the
minimum-supported-rust-version to 1.78. Additionally the nightly used in
testing in CI is updated as well.
prtest:full
* Fix compat with latest nightly in tests
* Fix some more nightly warnings
* Ignore new tests on MIRI
* Add v128.const support to Winch
* Remove next_vr and vector_reg_for methods
* Adjust alignment and slot size for v128
* Forgot to update disas tests
* Update unit tests
* Use 8 byte stack slot sizes
* Fix broken unit tests, add tests for vecs, and use ty size for vecs
* Update wasm-tools and wit-bindgen crates
This keeps things updated and pulls in some new features from
wasm-tools:
* Multiple returns in the component model are now gated by default. This
is reflected in a new `Config` option and CLI flag. The hope is to
remove this feature is no one ends up needing it.
* Support for more `shared` things were added but the feature is always
disabled so internal handlers just panic.
Tests were updated to not use multiple returns where appropriate, except
for one test which is specifically testing for multiple returns and how
it's reflected into the Rust type system.
* Fix fuzz build
This commit adds support for a new `--argv0` flag to the `wasmtime run`
CLI (and only `wasmtime run`, not other subcommands). This flag is used
to override the inferred value of the first argument which is sometimes
used to dispatch on various pieces of functionality. This enables
avoiding the need to copy around wasm files.
Closes#8955
* Introduce `wasmtime::StructRef` and allocating Wasm GC structs
This commit introduces the `wasmtime::StructRef` type and support for allocating
Wasm GC structs from the host. This commit does *not* add support for the
`struct.new` family of Wasm instructions; guests still cannot allocate Wasm GC
objects yet, but initial support should be pretty straightforward after this
commit lands.
The `StructRef` type has everything you expect from other value types in the
`wasmtime` crate:
* A method to get its type or check whether it matches a given type
* An implementation of `WasmTy` so that it can be used with `Func::wrap`-style
APIs
* The ability to upcast it into an `AnyRef` and to do checked downcasts in the
opposite direction
There are, additionally, methods for getting, setting, and enumerating a
`StructRef`'s fields.
To allocate a `StructRef`, we need proof that the struct type we are allocating
is being kept alive for the duration that the allocation may live. This is
required for many reasons, but a basic example is getting a struct instance's
type from the embedder API: this does a type-index-to-`StructType` lookup and
conversion and if the type wasn't kept alive, then the type-index lookup will
result in what is logically a use-after-free bug. This won't be a problem for
Wasm guests (when we get around to implementing allocation for them) since their
module defines the type, the store holds onto its instances' modules, and the
allocation cannot outlive the store. For the host, we need another method of
keeping the object's type alive, since it might be that the host defined the
type and there is no module that also defined it, let alone such a module that
is being kept alive in the store.
The solution to the struct-type-lifetime problem that this commit implements for
hosts is for the store to hold a hash set of `RegisteredType`s specifically for
objects which were allocated via the embedder API. But we also don't want to do
a hash lookup on every allocation, so we also implement a `StructRefPre` type. A
`StructRefPre` is proof that the embedder has inserted a `StructType`'s inner
`RegisteredType` into a store. Structurally, it is a pair of the struct type and
a store id. All `StructRef` allocation methods require a `StructRefPre`
argument, which does a fast store id check, rather than a whole hash table
insertion.
I opted to require `StructRefPre` in all allocation cases -- even though this
has the downside of always forcing callers to create one before they allocate,
even if they are only allocating a single object -- because of two
reasons. First, this avoids needing to define duplicate methods, with and
without a `StructRefPre` argument. Second, this avoids a performance footgun in
the API where users don't realize that they *can* avoid extra work by creating a
single `StructRefPre` and then using it multiple times. Anecdotally, I've heard
multiple people complain about instantiation being slower than advertised but it
turns out they weren't using `InstancePre`, and I'd like to avoid that situation
for allocation if we can.
* Move `allow(missing_docs)` up to `gc::disabled` module instead of each `impl`
* Rename `cast` to `unchecked_cast`
* fix `GcHeapOutOfMemory` error example in doc example
* document additional error case for `StructRef::new`
* Use `unpack` method instead of open-coding it
* deallocate on failed initialization
* Refactor field access methods to share more code
And define `fields()` in terms of `field()` rather than the other way around.
* Add upcast methods from structref to anyref
* Remove duplicate type checking and add clarifying comments about initializing vs writing fields
* make the `PodValType` trait safe
* fix benchmarks build
* prtest:full
* add miri ignores to new tests that call into wasm
* winch: Consolidate memory tests in `test/all/memory.rs`
This commit updates the memory tests to use
`wasmtime_test_macros::wasmtime_test` where applicable. This change
consolidates Winch's integration test suite into Wasmtime's general
test suite.
Note that this change doesn't update `wasmtime_test` to account for
pooling allocation configuration. I can either update the macro in this
PR or do it as a follow-up change once we decide to migrate
`tests/all/pooling_allocator.rs`.
* Remove `winch` mod from `tests/main.rs`
This commit is aimed at fixing an accidental regression from #8861 where
the `wasmtime serve` subcommand stopped reporting some instances of
authority and scheme. After discussion in #8878 the new logic
implemented is:
* Creation of an incoming request now explicitly requires specifying a
scheme which is out-of-band information about how the surrounding
server received the request.
* The authority is stored separately within a request and is inferred
from the URI's authority or the `Host` header if present. If neither
are present then an error is returned.
Closes#8878
* Wasmtime: Pop GC LIFO roots even when there is no GC heap
We can create and root `i31ref`s without ever allocating a GC heap for the
store, so we can't guard popping LIFO roots on the presence of a GC heap or else
we risk unbounded growth of the LIFO root set.
* Fix build with the gc feature disabled
* Update the wasm-tools family of crates
This notably brings in a limitation where component model flags types
must have 32 or fewer flags in accordance with the transition plan of
https://github.com/WebAssembly/component-model/issues/370. A feature
flag is added to go back to the previous behavior to avoid breaking
anyone too much.
This additionally brings in a fix for a panic when validating invalid
modules with tail calls.
* Add vet entries
This commit fixes writes to stdout/stderr which don't end in a newline
to not get split across lines with a prefix on each line. Instead
internally a flag is used to track whether a prefix is required at the
beginning of each chunk.
In the original development of this feature, guided by JS AOT
compilation to Wasm of a microbenchmark heavily focused on IC sites, I
was seeing a ~20% speedup. However, in more recent measurements, on full
programs (e.g., the Octane benchmark suite), the benefit is more like
5%.
Moreover, in #8870, I attempted to switch over to a direct-mapped cache,
to address a current shortcoming of the design, namely that it has a
hard-capped number of callsites it can apply to (50k) to limit impact on
VMContext struct size. With all of the needed checks for correctness,
though, that change results in a 2.5% slowdown relative to no caching at
all, so it was dropped.
In the process of thinking through that, I discovered the current design
on `main` incorrectly handles null funcrefs: it invokes a null code pointer,
rather than loading a field from a null struct pointer. The latter was
specifically designed to cause the necessary Wasm trap in #8159, but I
had missed that the call to a null code pointer would not have the same
effect. As a result, we actually can crash the VM (safely at least, but
still no good vs. a proper Wasm trap!) with the feature enabled. (It's
off by default still.) That could be fixed too, but at this point with
the small benefit on real programs, together with the limitation on
module size for full benefit, I think I'd rather opt for simplicity and
remove the cache entirely.
Thus, this PR removes call-indirect caching. It's not a direct revert
because the original PR refactored the call-indirect generation into
smaller helpers and IMHO it's a bit nicer to keep that. But otherwise
all traces of the setting, code pre-scan during compilation and special
conditions tracked on tables, and codegen changes are gone.
* cranelift-entity: Implement `EntitySet` in terms of `cranelift_bitset::CompoundBitSet`
* Shrink the size of `CompoundBitSet` so we don't perturb vmctx size test expectations
* Update vmctx size test expectations anyways because we shrunk "too much"
* Move `cranelift-bitset` to the front of `CRATES_TO_PUBLISH`
* Implement semver compatibility for exports
This commit is an implementation of component model semver compatibility
for export lookups. Previously in #7994 component imports were made
semver-aware to ensure that bumping version numbers would not be a
breaking change. This commit implements the same feature for component
exports. This required some refactoring to move the definition of semver
compat around and the previous refactoring in #8786 enables frontloading
this work to happen before instantiation.
Closes#8395
* Review comments
* Fix tests
* Update the wasi_testsuite submodule
This commit updates the wasi_testsuite submodule which we haven't
updated in a little over a year and applies a few small fixes but mostly
ignores new tests.
* Add another ignore#
* Un-nest exports in a component
This commit flattens the representation of exports in a component to
make them more easily indexable without forcing traversal through the
hierarchy of instance imports/exports to get there.
* Guarantee type information on component exports
Don't have it optional in some cases and present in others, instead
ensure there's type information for all component exports immediately
available.
* Refactor how component instance exports are loaded
This commit is a change to Wasmtime's public API for
`wasmtime::component::Instance` that reorganizes how component exports
are loaded. Previously there was a system where `Instance::exports()`
was called that that was sort of "iterated over" in a builder-style
pattern to acquire the actual export desired. This required lifetime
trickery for nested instances and some unfortunate API bloat. The major
downside of this approach is that it requires unconditional string
lookups at runtime for exports and additionally does not serve as a
great place to implement the semver-compatible logic of #8395. The goal
of this refactoring is to pave the way to improving this.
The new APIs for loading exports now look a bit more similar to what's
available for core modules. Notably there's a new
`Component::export_index` method which enables performing a string
lookup and returning an index. This index can in turn be passed to
`Instance::get_*` to skip the string lookup when exports are loaded. The
`Instance::exports` API is then entirely removed and dismantled.
The only piece remaining is the ability to load nested exports which is
done through an `Option` parameter to `Component::export_index`. The
way to load a nested instance is now to first lookup the instance with
`None` as this parameter an then the instance itself is `Some` to look
up an export of that instance. This removes the need for a
recursive-style lifetime-juggling API from wasmtime and in theory helps
simplify the usage of loading exports.
* Update `bindgen!` generated structures for exports
This commit updates the output of `bindgen!` to have a different setup
for exports of worlds to handle the changes from the previous commit.
This introduces new `*Pre` structures which are generated alongside the
existing `Guest` structures for example. The `*Pre` versions contain
`ComponentExportIndex` from the previous commit and serve as a path to
accelerating instantiation because all name lookups are skipped.
* Update test expectations for `bindgen!`-generated output
* Review comments
* Fix doc link
* Const-propagate some offsets in `VMOffsets`
Before this commit all offsets to all fields in `VMOffsets` were stored
as fields within `VMOffset` itself. All of the fields at the start of
`VMOffsets`, however, are statically known given the pointer size.
Notably this means that the use of `HostPtr` in the runtime still was
forcing a dynamic lookup of these static offsets.
This commit refactors this to reflect all static offsets based solely on
the pointer size in the `PtrSize` trait, removing all the fields from
`VMOffsets`. All the dynamically sized fields, however, remain in
`VMOffsets`.
* Fix expected error message
* Initial migration to `wasmtime_test`
This commit introduces the initial migration to the `wasmtime_test`
macro.
This change starts by migrating all the applicable `func.rs` integration
tests and at the same time it removes all the duplicated integration
tests in `winch.rs`.
Additionally, this change introduces a slight change to how the macro
works. Inspired by https://github.com/bytecodealliance/wasmtime/pull/8622#pullrequestreview-2083046911
it defaults to including all the known configuration combinations and
allows the macro user to opt-out where applicable. This makes the usage
of the macro less verbose.
The intention is to follow-up with subsequent PRs to migrate the all the
applicable tests.
* Remove unused `bail` import
* Add the ability to specify `wasm_features`
This commit adds the ability to specify `wasm_features` when invoking
the macro.
If the feature is off by default, the macro will ensure that the feature
is enabled in the resulting config.
If the feature is not supported by any of the compiler strategies, no
tests will be generated for such strategy.
Rather than digging only the embedder's store-specific data out and
passing that along, pass access to the entire Store. This is the same
thing we do for epoch interruption hooks, including the annoyance of
having to take the callback out of the store temporarily while calling
it to avoid having multiple mutable borrows.
* Wasmtime: Implement the custom-page-sizes proposal
This commit adds support for the custom-page-sizes proposal to Wasmtime:
https://github.com/WebAssembly/custom-page-sizes
I've migrated, fixed some bugs within, and extended the `*.wast` tests for this
proposal from the `wasm-tools` repository. I intend to upstream them into the
proposal shortly.
There is a new `wasmtime::Config::wasm_custom_page_sizes_proposal` method to
enable or disable the proposal. It is disabled by default.
Our fuzzing config has been updated to turn this feature on/off as dictated by
the arbitrary input given to us from the fuzzer.
Additionally, there were getting to be so many constructors for
`wasmtime::MemoryType` that I added a builder rather than add yet another
constructor.
In general, we store the `log2(page_size)` rather than the page size
directly. This helps cut down on invalid states and properties we need to
assert.
I've also intentionally written this code such that supporting any power of two
page size (rather than just the exact values `1` and `65536` that are currently
valid) will essentially just involve updating `wasmparser`'s validation and
removing some debug asserts in Wasmtime.
* Update error string expectation
* Remove debug logging
* Use a right shift instead of a division
* fix error message expectation again
* remove page size from VMMemoryDefinition
* fix size of VMMemoryDefinition again
* Only dynamically check for `-1` sentinel for 1-byte page sizes
* Import functions that are used a few times
* Better handle overflows when rounding up to the host page size
Propagate errors instead of returning a value that is not actually a rounded up
version of the input.
Delay rounding up various config sizes until runtime instead of eagerly doing it
at config time (which isn't even guaranteed to work, so we already had to have a
backup plan to round up at runtime, since we might be cross-compiling wasm or
not have the runtime feature enabled).
* Fix some anyhow and nostd errors
* Add missing rounding up to host page size at runtime
* Add validate feature to wasmparser dep
* Add some new rounding in a few places, due to no longer rounding in config methods
* Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` test
The point of the test is to ensure that we hit the limiter, so just cancel the
allocation from the limiter, and otherwise avoid MIRI attempting to allocate a
bunch of memory after we hit the limiter.
* prtest:full
* Revert "Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` test"
This reverts commit ccfa34a78dd3d53e49a6158ca03077d42ce8bcd7.
* miri: don't attempt to allocate more than 4GiB of memory
It seems that rather than returning a null pointer from `std::alloc::alloc`,
miri will sometimes choose to simply crash the whole program.
* remove duplicate prelude import after rebasing
This commit is a fix to Wasmtime's DWARF processing transform to correct
the meaning of the `.debug_loc` section. This section's addresses are
relative to the `DW_AT_low_pc` entry located in the
`DW_TAG_compile_unit` container, but Wasmtime's construction of this
section didn't take this into account. Instead all addresses in
`.debug_loc` are relative to the start of the compiled object, not to
the start of the compile unit itself. This commit fixes this by
unconditionally describing `DW_TAG_compile_unit` locations with
`DW_AT_ranges` instead of `DW_AT_low_pc`. This ends up fixing debug
information for debug information using `.debug_loc` with multiple
codegen units.
Closes#8752
* Make module ids unique per-process, not per-engine
Currently all instances of `wasmtime::Module` have a unique 64-bit id
embedded into them. This ID was originally only used for affinity in the
pooling allocator as a quick check of module equality. This use case
only required engine-local ids so the initial implementation had an ID
allocator per-engine.
Later, however, this id was reused for `wasmtime::ModuleExport` which
was intended to skip the string lookup for an export at runtime. This
also stored a module id but it did not store an engine identifier. This
meant that it's possible to mix these up and pass the wrong export to
the wrong engine. This behavior can lead to a runtime panic in Wasmtime.
This commit fixes this by making the module identifier be global
per-process instead of per-engine. This mirrors how store IDs are
allocated where they're per-process instead of per-engine. The same
logic for why store IDs are unlikely to be exhausted applies here too
where this 64-bit space of identifiers is unlikely to be exhausted.
* Fix warnings
* Fix tests
This commit resolves an assert in the dwarf generating of core wasm
modules when the module has a defined linear memory which is flagged
`shared`. This is represented slightly differently in the `VMContext`
than owned memories that aren't `shared`, and looks more like an
imported memory. With support in #8740 it's now much easier to support
this.
Closes#8652
This commit updates the native-DWARF processing (the `-D debug-info` CLI
flag) to support components. Previously component support was not
implemented and if there was more than one core wasm module within a
component then dwarf would be ignored entirely.
This commit contains a number of refactorings to plumb a more full
compilation context throughout the dwarf processing pipeline. Previously
the data structures used only were able to support a single module. A
new `Compilation` structure is used to represent the results of an
entire compilation and is plumbed through the various locations. Most of
the refactorings in this commit were then to extend loops to loop over
more things and handle the case where there is more than one core wasm
module.
I'll admit I'm not expert on DWARF but basic examples appear to work
locally and most of the additions here seemed relatively straightforward
in terms of "add another loop to iterate over more things" but I'm not
100% sure how well this will work. In theory this now supports
concatenating DWARF sections across multiple core wasm modules, but
that's not super well tested.
This is more-or-less a prerequisite for #8652 and extends the generated
dwarf with expressions to not only dereference owned memories but
additionally imported memories which involve some extra address
calculations to be emitted in the dwarf.
This reverts part of #7863 which was a misunderstanding on my part
about `SO_REUSEADDR`. I think I mixed it up with `SO_REUSEPORT`. Without
`SO_REUSEADDR` it's possible to have this happen on Unix:
* Start a `wasmtime serve` session
* Connect to the session with `nc`
* Kill the server
* Restarting the server no longer works
Due to the active TCP connection at the time the server was killed the
socket/address is in the `TIME_WAIT` state which apparently prevents
rebinding the port until the OS has a chance to clean up everything.
Setting `SO_REUSEADDR` enables rebinding the address quickly.
Now in #7863 that was trying to fix#7852 which said that it was
possible to have multiple `wasmtime serve` instances binding the same
port. That can lead to confusion and is generally something we don't
want. That being said #7863 only fixed the issue for Windows but ended
up making Unix worse. This PR restores more reasonable behavior for both
Unix and Windows by conditionally setting the `SO_REUSEADDR` based on
the platform.
This PR additionally adds two new tests, both for rebinding an in-use
port quickly and additionally ensuring the same port can't be listened
to twice.
* Complete implementation in wasmtime
* Get the impl of IntoFunc to point at the new HostContext from_closure method to tie it back to the new implementation
* A little bit of cleanup to comments and naming
* Update doc comment for Func wrap_async
* wasmtime: Introduce the `test-macros` crate
This commit introduces the `test-macros` crate. The whole idea behind this crate is to export a single or multiple macros to make it easier to configure Wasmtime for integration tests. The main use-case at this time, is running a subset of the integration tests with Cranelift and Winch. This crate could be extended to serve other use-cases, like testing pooling allocator and/or GC configurations.
This commit introduces a single example of how this macro could be used. If there's agreement on merging this change in some shape or form, I'll follow up with migrating the current tests to use `#[wasmtime_test]` where applicable.
Part of what's implemented in this PR was discussed in Cranelift's meeting on [April 24th, 2024](https://github.com/bytecodealliance/meetings/blob/main/cranelift/2024/cranelift-04-24.md), however there are several discussion points that are still "in the air", like for example, what's the best way to avoid the combinatorial explosion problem for the potential test matrix.
* Add crate license
* Clippy fixes
* Remove test-macros from members
* Clean up test-macros Cargo.toml
- Fix version
- Add `[lints]`
- Add publish key
* Add `TestConfig` and simpify parsing
This commit adds a `TestConfig` struct that holds the supported Wasmtime
test configuration. Additonally this commit introduces a partial
function parser, in which only the attributes, visibility, and signature
are fully parsed, leaving the function body as an opaque `TokenStream`
This commit removes the support in the `wasmtime` CLI for old CLI
options which were present in Wasmtime 13 and prior. This compatibility
was added in #7385 and backported to the Wasmtime 14 release #7395.
Wasmtime 14.0.0, which did not have this compatibility shim, was
released on 2023-10-20. Wasmtime 14.0.3, which restored compatibility
with this shim, was released on 2023-10-30. This means that Wasmtime
since 2023-10-30 has been warning users about differences in the old and
new CLI.
This commit will be released with Wasmtime 22 which will means that
users will have had an 8-month transition window for warnings to
migrate. The hope is that this is sufficient but it's also not too too
burdensome to carry for longer if necessary.
* Fix tail calls being turned on by default
Logic in `Config` to conditionally enable tail calls wasn't handling the
case where the configured compiler strategy was `Strategy::Auto` meaning
that by default tail calls weren't actually enabled. This commit
refactors handling of `Strategy` to avoid storing `Strategy::Auto` in
`CompilerConfig` so tests against it can use either cranelift or winch.
* Update disas tests
* Update Winch tests to using winch
* Implement Component::define_unknown_imports_as_traps
This will search through a components imports, find any imports
that have not yet been defined in the linker and add a definition
which will trap upon being called.
* Address PR feedback
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Small refactoring
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
---------
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Use bytes for maximum size of linear memory with pooling
This commit changes configuration of the pooling allocator to use a
byte-based unit rather than a page based unit. The previous
`PoolingAllocatorConfig::memory_pages` configuration option configures
the maximum size that a linear memory may grow to at runtime. This is an
important factor in calculation of stripes for MPK and is also a
coarse-grained knob apart from `StoreLimiter` to limit memory
consumption. This configuration option has been renamed to
`max_memory_size` and documented that it's in terms of bytes rather than
pages as before.
Additionally the documented constraint of `max_memory_size` must be
smaller than `static_memory_bound` is now additionally enforced as a
minor clean-up as part of this PR as well.
* Review comments
* Fix benchmark build
This fixes an accidental regression from #8616 where page alignment was
implicitly happening due to how configuration was processed but it
wasn't re-added in the refactoring.
Nick Fitzgerald
Philip Craig
Alex Crichton
Dave Bakker
Hamir Mahal
Ulrich Weigand
Xinzhao Xu
Jeffrey Charles
Saúl Cabrera
Chris Fallin
Jamey Sharp
Shane Snover
Ryan Levick
FrankReh