Skip to content

Add support for map type#12216

Merged
alexcrichton merged 26 commits intobytecodealliance:mainfrom
yordis:yordis/feat-map-support
Mar 9, 2026
Merged

Add support for map type#12216
alexcrichton merged 26 commits intobytecodealliance:mainfrom
yordis:yordis/feat-map-support

Conversation

@yordis
Copy link
Contributor

@yordis yordis commented Dec 23, 2025

@yordis yordis force-pushed the yordis/feat-map-support branch 3 times, most recently from 6b6f675 to cd2282b Compare December 23, 2025 21:53
@github-actions github-actions bot added wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:c-api Issues pertaining to the C API. wasmtime:config Issues related to the configuration of Wasmtime wizer Issues related to Wizer snapshotting, pre-initialization, and the `wasmtime wizer` subcommand labels Dec 23, 2025
@github-actions
Copy link

Subscribe to Label Action

cc @fitzgen

Details This issue or pull request has been labeled: "wasmtime:api", "wasmtime:c-api", "wasmtime:config", "wizer"

Thus the following users have been cc'd because of the following labels:

  • fitzgen: wizer

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@github-actions
Copy link

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

  • If you added a new Config method, you wrote extensive documentation for
    it.

    Details

    Our documentation should be of the following form:

    Short, simple summary sentence.
    
    More details. These details can be multiple paragraphs. There should be
    information about not just the method, but its parameters and results as
    well.
    
    Is this method fallible? If so, when can it return an error?
    
    Can this method panic? If so, when does it panic?
    
    # Example
    
    Optional example here.
    
  • If you added a new Config method, or modified an existing one, you
    ensured that this configuration is exercised by the fuzz targets.

    Details

    For example, if you expose a new strategy for allocating the next instance
    slot inside the pooling allocator, you should ensure that at least one of our
    fuzz targets exercises that new strategy.

    Often, all that is required of you is to ensure that there is a knob for this
    configuration option in wasmtime_fuzzing::Config (or one
    of its nested structs).

    Rarely, this may require authoring a new fuzz target to specifically test this
    configuration. See our docs on fuzzing for more details.

  • If you are enabling a configuration option by default, make sure that it
    has been fuzzed for at least two weeks before turning it on by default.


Details

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

@alexcrichton
Copy link
Member

On a skim this looks like it's all in the right direction, thanks! As as a heads up the wasm-tools deps will be updated in #12254 which'll avoid the need for git deps. I'll take a closer look once this is further along in CI passing tests

@yordis yordis force-pushed the yordis/feat-map-support branch 5 times, most recently from db45a3a to 83dd7a7 Compare January 8, 2026 10:17
@github-actions github-actions bot added the fuzzing Issues related to our fuzzing infrastructure label Jan 8, 2026
@github-actions
Copy link

github-actions bot commented Jan 8, 2026

Subscribe to Label Action

cc @fitzgen

Details This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

  • fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@yordis yordis force-pushed the yordis/feat-map-support branch from 83dd7a7 to b9ca740 Compare January 8, 2026 19:19
Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking quite good to me, thanks for the thorough tests!

I haven't scrutinized the trampoline generation nor the lifting/lowering yet, but I can do that once the tests added here are passing (the #[ignore] ones at least).

If you can one thing I'd also recommend is modeling as many tests as possible as a *.wast test since that's generally the easiest to run and share (albeit difficult to write and debug)

@yordis yordis force-pushed the yordis/feat-map-support branch from 301e19b to d291adf Compare February 6, 2026 06:26
@yordis yordis requested a review from alexcrichton February 10, 2026 20:12
@yordis yordis force-pushed the yordis/feat-map-support branch from ddac63a to b6376cb Compare February 16, 2026 23:06
@yordis yordis marked this pull request as ready for review February 16, 2026 23:07
@yordis yordis requested review from a team as code owners February 16, 2026 23:07
Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly some thoughts about deduplication/sharing of the gnarliest bits below --

@yordis yordis force-pushed the yordis/feat-map-support branch from b6376cb to e644b8b Compare February 27, 2026 01:21
@yordis
Copy link
Contributor Author

yordis commented Feb 27, 2026

@alexcrichton addressed the comments, about the sharing stuff, feedback welcome there, I am not sure if it is the best way or not; not sure what you had in mind

yordis added 20 commits March 9, 2026 19:07
This commit introduces support for HashMap<K, V> in the component model, allowing maps to be represented as list<tuple<K, V>> in the canonical ABI. It includes implementations for the ComponentType, Lower, and Lift traits for HashMap, enabling type checking, lowering to flat representations, and lifting from memory. Additionally, the maximum depth for type generation in the fuzzing utility is updated to accommodate the new map type.
This commit removes the previous wasm features configuration and adds new functions for creating a map-configured engine. The `map_config` and `map_engine` functions are introduced to facilitate the use of the component model with maps in tests, ensuring that the engine is properly configured for map types in the component model.
…existing tests

This commit introduces a new WAST test file specifically for testing various map types in the component model. Additionally, it removes the redundant map type definitions from the existing types.wast file to streamline the test suite.
…ved iteration and memory management. Introduce new implementations for ComponentType, Lower, and Lift traits for std::collections::HashMap, enhancing support for map types in the component model.
The translate_map function had two categories of bugs preventing map
adapter trampolines from working:

1. Wasm stack discipline: local_set_new_tmp emits LocalSet which pops
   from the stack, but was called when the stack was empty (to
   "pre-allocate" locals). Fixed by computing values first, then
   calling local_set_new_tmp to consume them—matching translate_list's
   pattern. Also removed an erroneous LocalTee that left an orphan
   value on the stack. Affected: src_byte_len, dst_byte_len,
   cur_src_ptr, cur_dst_ptr.

2. Pointer advancement: after value translation, the pointer still
   points at the value start. The code only advanced by trailing
   padding instead of value_size + trailing_padding, causing every
   loop iteration to re-read the same memory.

Also fixes entry layout to use proper record alignment rules (entry
align = max(key_align, value_align), value at aligned offset).
Val::Map already holds Vec<(Val, Val)> which derefs to &[(Val, Val)],
matching lower_map's signature directly. The intermediate Vec allocation
and deep clone of every key/value pair was redundant.
- component_fuzz: use saturating_sub in generate_hashable_key to prevent
  underflow when fuel is 0 and Enum variant is chosen
- typed: remove incorrect ? operators in lift_map for hashbrown::HashMap
  (with_capacity and insert don't return Result)
Compute map entry ABI and value offsets once during type building, and reuse that metadata in runtime map lift/lower paths instead of recalculating tuple layout at each call site.
Bundle map lift/lower layout and type metadata into a small MapAbi32 helper so map helper calls stay concise without changing behavior.
@yordis yordis force-pushed the yordis/feat-map-support branch 2 times, most recently from 1802a87 to 2898eee Compare March 9, 2026 23:15
…rary_val

The fuzzer's component_api oracle was generating map types but the engine
didn't have the map feature enabled, and arbitrary_val had no arm for
Type::Map. Enable component_model_map in the store helper (matching how
component_model_async is forced on) and implement arbitrary value generation
for map types.
@yordis yordis force-pushed the yordis/feat-map-support branch from 2898eee to 36008b6 Compare March 9, 2026 23:18
@alexcrichton alexcrichton enabled auto-merge March 9, 2026 23:23
@alexcrichton alexcrichton added this pull request to the merge queue Mar 9, 2026
Merged via the queue into bytecodealliance:main with commit 1b59b57 Mar 9, 2026
49 checks passed
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Mar 10, 2026
In reading over bytecodealliance#12216 I found a few related but also somewhat
orthogonal refactors that I wanted to implement, and thus this commit.
Changes here are:

* Handling pointer pairs for lists/maps/strings is now more uniform with
  a single set of functions doing the lift/lower to flat/memory. Less
  "FIXME 4311" spread throughout effectively.

* Conditional defines and organization of the `HashMap`-related impls
  were tweaked, for example impls on `HashMap` are now unconditional as
  well as `TryHashMap`. Some internals were refactored to in theory
  reduce complexity, but this is also subjective.

* Lifting a `map<K, V>` now consumes fuel, a recent change, to ensure
  that resource exhaustion in the host is limited.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fuzzing Issues related to our fuzzing infrastructure wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:c-api Issues pertaining to the C API. wasmtime:config Issues related to the configuration of Wasmtime wizer Issues related to Wizer snapshotting, pre-initialization, and the `wasmtime wizer` subcommand

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants