Configure WIT feature gates at runtime & implement wasi-cli exit-with-code#9381
Conversation
…mit all unstable members. These features will be gated at runtime.
…ns in for worlds/interfaces that use any unstable feature.
4fcfe6f to
050d5f7
Compare
alexcrichton
left a comment
There was a problem hiding this comment.
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_linkerretains theLinkOptionsparameter - Top-level
add_to_linkerloses theLinkOptionsparameter, and there's a new top-leveladd_to_linker_with_optionsfunction?
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.
…it was and add new variants that take the option parameters.
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 |
alexcrichton
left a comment
There was a problem hiding this comment.
Ah sorry for my rambling, this is exactly what I was thinking 👍
|
Try again please |
|
Sigh. Try again, again? |
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.
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.
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
featuresoption ofwasmtime::component::bindgen!. That option has been removed. Bindings for unstable APIs are now generated unconditionally. Instead, the generatedadd_to_linker***functions take an additionalLinkOptionsparameter if the world/interface has any unstable features. The availability of unstable features is now controlled through that.The component bindgen generates a fresh
LinkOptionstype for eachinterfacethat needs it and a singleLinkOptionstype 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.witproduces: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-codeCLI flag.@sunfishcode, if I interpret WebAssembly/wasi-cli#11 correctly, you were OK with removing the Windows-specific restriction, right? See: badeend@2f48c77