Skip to content

Configure WIT feature gates at runtime & implement wasi-cli exit-with-code#9381

Merged
alexcrichton merged 15 commits into
bytecodealliance:mainfrom
badeend:unstable-features
Oct 7, 2024
Merged

Configure WIT feature gates at runtime & implement wasi-cli exit-with-code#9381
alexcrichton merged 15 commits into
bytecodealliance:mainfrom
badeend:unstable-features

Conversation

@badeend

@badeend badeend commented Oct 6, 2024

Copy link
Copy Markdown
Member

For extra context, see: #9276


This PR adds the ability to enable/disable WIT APIs gated by @unstable(feature = ...) at link-time.

Previously, unstable features could only be controlled at compile-time through the features option of wasmtime::component::bindgen!. That option has been removed. Bindings for unstable APIs are now generated unconditionally. Instead, the generated add_to_linker*** functions take an additional LinkOptions parameter if the world/interface has any unstable features. The availability of unstable features is now controlled through that.

The component bindgen generates a fresh LinkOptions type for each interface that needs it and a single LinkOptions type for the entire world, which is a union of all the options contained in that world. An example is included in the component-macro tests: unstable-features.wit produces:
https://github.com/badeend/wasmtime/compare/245dcab34c2fcae69e0f6c3f2daa15837ea6ff61..4fcfe6f866f36ed663f24199e1744bed3cf0bc2c#diff-ad635965474c257cbafce510463aaf52c1ac813f22168045ae22546d3b3ebfc6


A happy coincidence is that WASI-0.2.1 already includes a tiny but practical first use case: exit-with-code.
I've implemented that function and is gated behind the -Scli-exit-with-code CLI flag.

@sunfishcode, if I interpret WebAssembly/wasi-cli#11 correctly, you were OK with removing the Windows-specific restriction, right? See: badeend@2f48c77

@badeend badeend requested a review from a team as a code owner October 6, 2024 10:40
@badeend badeend requested review from fitzgen and removed request for a team October 6, 2024 10:40
@badeend badeend force-pushed the unstable-features branch from 4fcfe6f to 050d5f7 Compare October 6, 2024 10:42
@github-actions github-actions Bot added the wasi Issues pertaining to WASI label Oct 6, 2024

@alexcrichton alexcrichton left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This looks great to me, thanks for this!

In retrospect though given the large number of changes related to add_to_linker what do you think about:

  • Interface/world-level add_to_linker retains the LinkOptions parameter
  • Top-level add_to_linker loses the LinkOptions parameter, and there's a new top-level add_to_linker_with_options function?

Or perhaps this would only affect the helpers we have in wasmtime-wasi and wasmtime-wasi-http? Basically it looks like there should be a convenience function for "default options" rather than requiring all callers to call it.

Comment thread crates/wit-bindgen/src/lib.rs Outdated
@badeend

badeend commented Oct 7, 2024

Copy link
Copy Markdown
Member Author
  • Interface/world-level add_to_linker retains the LinkOptions parameter
  • Top-level add_to_linker loses the LinkOptions parameter, and there's a new top-level add_to_linker_with_options function?

Don't know what top-level function you're referring to. I think the Interface/world-level add_to_linker functions are the only ones generated by the bindgen?

I have just updated the wasmtime-wasi's functions back to their old signature and added an extra set of _with_options variants. I didn't touch the add_to_linker functions generated by bindgen.

@alexcrichton alexcrichton left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ah sorry for my rambling, this is exactly what I was thinking 👍

@alexcrichton alexcrichton added this pull request to the merge queue Oct 7, 2024
@github-merge-queue github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 7, 2024
@badeend

badeend commented Oct 7, 2024

Copy link
Copy Markdown
Member Author

Try again please

@alexcrichton alexcrichton enabled auto-merge October 7, 2024 19:17
@alexcrichton alexcrichton added this pull request to the merge queue Oct 7, 2024
@github-merge-queue github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 7, 2024
@badeend

badeend commented Oct 7, 2024

Copy link
Copy Markdown
Member Author

Sigh.

Try again, again?

@alexcrichton alexcrichton enabled auto-merge October 7, 2024 20:21
@alexcrichton alexcrichton added this pull request to the merge queue Oct 7, 2024
Merged via the queue into bytecodealliance:main with commit c230353 Oct 7, 2024
benbrandt added a commit to benbrandt/wasmtime that referenced this pull request Dec 14, 2024
It seems that this was removed in bytecodealliance#9381

The new method is really nice for controlling this at runtime, however the docs still mentioned the old behavior.
github-merge-queue Bot pushed a commit that referenced this pull request Dec 16, 2024
It seems that this was removed in #9381

The new method is really nice for controlling this at runtime, however the docs still mentioned the old behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasi Issues pertaining to WASI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants