Don't rely purely on `compile_error!` which doesn't halt compilation.
Instead fill out some stubs which won't ever actually get compiled but
prevent other compiler errors from cropping up.
* Add an unsafe API to unload process trap handlers
This commit adds a new unsafe API `Engine::unload_process_handlers`
which can be used to de-initialize trap-handling state in a process. In
general this is an unsafe operation that we have no means of making
safe, hence the `unsafe`. There are particular situations where this can
be done safely though and this is provided for such situations. The
safety conditions rely on invariants that Wasmtime itself cannot
maintain so the burden is on callers to ensure that this is invoked in a
safe manner.
This is inspired by discussion [on Zulip][zulip] where Wasmtime's trap
handling infrastructure prevented unloading a DLL with Wasmtime in it.
There's possibly other reasons that unloading DLLs are unsafe in Rust
but it feels appropriate to at least provide this knob to embedders to
be able to turn if they like.
[zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/How.20to.20safely.20drop.20wasmtime.3F/near/453366905
* Review comments
* Update tests/unload-engine.rs
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Ignore new test on miri
---------
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Derive `Copy` for `Val`
* Fix `clippy::clone_on_copy` for the whole repo
* Enforce `clippy::clone_on_copy` for the workspace
* fix some more clippy::clone_on_copy that got missed
This removes `V128Abi`, which is no longer needed since we removed the native
calling convention from Wasmtime. For the new internal representation of `V128`,
we use an unaligned byte array. This lowers the alignment requirements for
`V128` to 1 rather than 16, which means that `Val` no longer requires padding
after its discriminant before the storage for its `V128` variant, which in turn
allows its size to shrink from 32 to 24 bytes.
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* 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
* 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
In the past, the wasmtime-runtime crate couldn't directly call
`get_wasm_trap` because the registry of loaded modules was in the
wasmtime crate, so it called through a global function pointer
registered with `init_traps` instead.
Since the two crates were merged in #8501, we no longer need this
indirection.
While I'm here, I've also split the former `get_wasm_trap` function into
two parts: `lookup_code` finds a loaded module that had been previously
registered with `register_code`, and the `lookup_trap_code` step is now
done by a helper on `CodeMemory`. This makes the module registry more
broadly useful.
I also simplified the code lookup step in two ways:
- I removed a redundant check from the code lookup. `BTreeMap::range`
will only return entries where `end >= pc`, so the `end < pc`
condition is always false.
- I used checked_sub instead of writing both the comparison and
subtraction explicitly.
Because they take a shared borrow of the store and return a shared borrow of
the `VMGcRef` with the same lifetime, and because performing a GC requires a
mutable borrow of the store, there actually was no reason to differentiate
between checked and unchecked methods or require `AutoAssertNoGc` arguments.
Fixes https://github.com/bytecodealliance/wasmtime/issues/8940
* 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
Adding `ty`, `matches_ty`, etc... methods that we have for other kinds of
values.
Cleaning up doc comments.
Add some same-store asserts.
Splitting this out from a larger PR to make review easier.
* Implement `Display` for `wasmtime-types` things
We were pretty much already implementing it already, and it is generally useful.
* Fix compiler errors (on non-nightly rust? shrug)
* A handful of little tweaks for GC types
Splitting this out from a larger PR so that it is easier to review and
everything can land quicker.
* Don't use `Cow`, just use references
This commit fixes an issue with static memory initialization and custom
page sizes interacting together on aarch64 Linux. (is that specific
enough?)
When static memory initialization is enabled chunks of memory to
initialize the linear memory are made in host-page-size increments of
memory. This is done to enable page-mapping via copy-on-write if
customized. With the custom page sizes proposal, however, for the first
time it's possible for a linear memory to be smaller than this chunk of
memory. This means that a virtual memory allocation of a single host
page can be made which is smaller than the initialization chunk.
This currently only happens on aarch64 Linux where we coarsely
approximate that the host page size is 64k but many hosts run with 4k
pages. This means that a 64k initializer is created but the host only
allocates 4k for a linear memory. This means that memory initialization
can crash when a 64k initializer is copied into a 4k memory.
This was not caught via fuzzing because fuzzing only runs on x86_64.
This was not caught via CI because on CI guard pages are disabled
entirely on QEMU and we got lucky in that a number of virtual memory
allocations were all placed next to each other meaning that this copy
was probably corrupting some other memory. Locally this was found by
running tests on `main` as-is on AArch64 Linux (by bjorn3).
This commit implements a few safeguards and a fix for this issue:
* On CI with QEMU modestly-size guard pages are now enabled to catch
this sooner in development should it happen again in the future.
* An `assert!` is added during memory initialization that the memory
copy is indeed valid. This causes the tests to fail as-is on `main`
even on x86_64.
* The issue itself is fixed by bailing out of static memory
initialization should the host page size exceed the wasm page size
which can now happen on aarch64 Linux with smaller page sizes.
* 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
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.
* Improve some documentation of the `wasmtime-wasi` crate
Show a few examples of using `with` to point to upstream `wasmtime-wasi`
for bindings.
* Refactor and document the `wasmtime-wasi-http` more
This commit primarily adds a complete example of using
`wasmtime-wasi-http` to the documentation. Along the way I've done a
number of other refactorings too:
* `bindgen!`-generated `*Pre` structures now implement `Clone`.
* `bindgen!`-generated `*Pre` structures now have an `engine` method.
* `bindgen!`-generated `*Pre` structures now have an `instance_pre` method.
* The structure of `wasmtime-wasi-http` now matches `wasmtime-wasi`,
notably:
* The `proxy` module is removed
* `wasmtime_wasi_http::add_to_linker_{a,}sync` is the top level
add-to-linker function.
* The `bindings` module now contains `Proxy` and `ProxyPre` along with
a `sync` submodule.
* The `bindings` module contains all bindings for `wasi:http` things.
* The `add_only_*` methods are un-hidden and documented.
* Code processing `req` has been simplified by avoiding
decomposing-and-reconstructing a request.
* The `new_incoming_request` method is now generic to avoid callers
having to do boxing/mapping themselves.
* Update expanded macro expectations
* Remove unused import
* upgrade to wasm-tools 0.211.1
* code review
* cargo vet: auto imports
* fuzzing: fix wasm-smith changes
* fuzzing: changes for HeapType
* Configure features on `Parser` when parsing
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
This commit raises the default setting of `max_memory_size` in the
pooling allocator from 10M to 4G. This won't actually impact the virtual
memory reserved in the pooling allocator because we already reserved 6G
of virtual memory for each linear memory this instead allows access to
all of it by default. This matches the default behavior of Wasmtime for
the non-pooling allocator which is to not artificially limit memory by
default.
The main impact of this setting is that the memory-protection-keys
feature, which is disabled by default, will have no effect by default
unless `max_memory_size` is also configured to something smaller than
4G. The documentation has been updated to this effect.
Closes#8846
I noticed that the wasm_memory64 flag was left out of Config's debug impl,
so rather than add it, I decided to use the `bitflags::Flags::FLAGS`
const to iterate the complete set of flags.
THe downside of this change is that it will print flags which do not
have a setter in Config, e.g. `wasm_component_model_nested_names`.
An alternative to this change is, rather than expanding out the single
`features: WasmFeatures` member into many different debug_struct fields,
the debug impl of WasmFeatures is used.
Here is a sample debug of Config with this change:
Config { debug_info: None, wasm_mutable_global: true, wasm_saturating_float_to_int: true, wasm_sign_extension: true, wasm_reference_types: true, wasm_multi_value: true, wasm_bulk_memory: true, wasm_simd: true, wasm_relaxed_simd: false, wasm_threads: false, wasm_shared_everything_threads: false, wasm_tail_call: false, wasm_floats: true, wasm_multi_memory: false, wasm_exceptions: false, wasm_memory64: false, wasm_extended_const: false, wasm_component_model: false, wasm_function_references: false, wasm_memory_control: false, wasm_gc: false, wasm_custom_page_sizes: false, wasm_component_model_values: false, wasm_component_model_nested_names: false, parallel_compilation: true, compiler_config: CompilerConfig { strategy: Some(Cranelift), target: None, settings: {"opt_level": "speed", "enable_verifier": "true"}, flags: {}, cache_store: None, clif_dir: None, wmemcheck: false }, parse_wasm_debuginfo: false }
* wasmtime: Add profile markers around host-calls
The output of the guest profiler can be misleading around hostcalls.
Whatever happened to be the last sample before the hostcall appears to
run for the entire time of the hostcall. This change ensures that we can
see the actual call stack at the time of the hostcall, and get a visual
indication of which periods are not spent executing guest code.
* wasmtime-cli needs wasmtime/call-hook, but wasmtime itself doesn't
In general, embedders that wish to use the new functionality likely will
need to enable the wasmtime/call-hook feature in order to get Wasmtime
to notify them of when to call into the profiler. However embedders
could consider other alternatives, such as calling the profiler from
selected hostcall implementations.
* 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
* 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
* Disable memory protection keys by default at compile time
This commit gates memory protection keys behind a new Cargo feature
which is disabled by default. Memory protection keys are already
disabled by default on all platforms and are only configured to possibly
work with Linux x64. When enabled, however, it unconditionally adds a
small amount of overhead to WebAssembly entries/exits even if the
feature is disabled at runtime for the same reason that the `call-hook`
feature adds overhead. With `call-hook` being disabled by default
in #8808 it seemed reasonable to additionally gate memory protection
keys to avoid needing to disable features in Wasmtime to get the best
performance wasm<->host calls.
* Enable Wasmtime feature for fuzzing
* Disable `call-hook` crate feature by default
This commit disables the `call-hook` feature for the Wasmtime crate
added in #8795 by default. The rationale is that this has a slight cost
to all embeddings even if the feature isn't used and it's not expected
to be that widely used of a feature, so off-by-default seems like a more
appropriate default.
* Enable all features in doc build
* More doc fixes
* 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
This commit skips the safety checks of `AutoAssertNoGc` for the duration
of host calls where the types involved are statically known to not
perform any GCs (e.g. integers and floats). This helps recover some
performance loss from indirect calls made on entry/exit of an
`AutoAssertNoGc` scope when the `gc` feature is enabled in Wasmtime.
* Add `anyhow` stuff to our internal `wasmtime` crate prelude
We use it basically everywhere and it is annoying to have to import.
I also did an audit of existing `use` statements and removed the now-redundant
ones and replaced one-off imports with usage of the prelude, so that the prelude
is available by default in more places.
* Fix `cargo doc`
* Migrate usage of the `memoffset` crate to `core::mem::offset_of!`
* C-string literals such as `c"foo"` are now possible
* Some helpers for fixed-length slices such as `slice::first_chunk_mut`
are starting to stabilize.
* Add a compile-time feature for call hooks
This commit moves the `Store::call_hook` API behind a Cargo feature
named `call-hook`. This helps speed up the path from wasm into the host
by avoiding branches at the start and the end of the execution. In a
thread on [Zulip] this is locally leading to significant performance
gains in this particular microbenchmark so having an option to disable
it at the crate layer seems like a reasonable way to thread this needle
for now. This definitely has a downside in that it requires a crate
feature at all, but I'm not sure of a better solution as LLVM can't
dynamically detect that `Store::call_hook` is never invoked and
therefore the branch can be optimized away.
[Zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Performance.20regression.20since.20rust.201.2E65/near/444505571
* Fix a feature build
When the pooling allocator is itself disabled then there's no use for
enabling MPK so this commit switches the implementation to all of the
disabled versions of the primitives. This notably makes `ProtectionKey`
an uninhabited `enum` meaning that `Option<ProtectionKey>` in the
`Store` is a zero-sized field and `.is_none()` returns a constant
`true`. This is on the hot path of entering/exiting wasm so can help
speed up things a bit there.
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
Replace it with an `enum` of the two possibilities that it can be. This
removes the need to have a trait dispatch indirection in the `vm`
module. Previously this was required as `wasmtime-runtime` was a
separate crate, but now it's no longer required.
* 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 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.
* 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
This is another take at improving the documentation for `bindgen!` in
Wasmtime. This commit takes a leaf out of the book of
bytecodealliance/wit-bindgen#871 to organize the documentation of the
macro a bit more rather than having one giant doc block that can be
difficult to explore. The macro's documentation itself is now mostly a
reference of all the options that can be specified. There is now a new
documentation-only module which serves a few purposes:
* Individual examples are organized per-submodule to be a bit more
digestable.
* Each example has an example of the generated code in addition to the
source code used for each example.
* All examples are tested on CI to compile (none are run).
My hope is that this makes it easier to expand the docs here further
over time with niche features as they arise or with various options that
the macro has. This is one of the lynchpins of Wasmtime's support for
the component model so it seems pretty important to have a good
onboarding experience here.
Along the way I've implemented a few more niche options for the
`bindgen!` macro that I found necessary, such as configuring the
`wasmtime` crate and where it's located.
Alex Crichton
Nick Fitzgerald
Jamey Sharp
Bruce Mitchener
Patrick Koenig
Chris Fallin
Pat Hickey
Theo Paris
Daniel Sedlak
Shane Snover
Philip Craig