Skip to content

Add a flag that constrains features to the W3C recommendation #1899

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
codefromthecrypt opened this issue Apr 14, 2022 · 7 comments
Open

Comments

@codefromthecrypt
Copy link

Since this is a repo in the org for the W3C core recommendation, I think it is a fair ask to have a flag that constrains features to what's included in that, and no more. It will help with tracking https://github.com/WebAssembly/wabt#supported-proposals and make upgrades seamless.

I'm not asking for this to be by default turned on, rather to make it possible to achieve undoing all the flags that turn on things not in the recommended spec. Ex. --enable-1.0 (please don't call whatever flag MVP as that's jargon and not a W3C version number).

Ex. just like enable-all

      --enable-1.0                             Enable only features in version 1.0 of the core WebAssembly standard
@codefromthecrypt
Copy link
Author

one nuance might be how this interacts with other flags.

ex. if you specify --enable-1.0 and also --enable-multi-value you get the combination of those, not only 1.0.

The use case I have is around spec additions for features themselves. the spectests include modules that may compile differently depending on what's enabled or not. When adding support for one feature, it is helpful to not accidentally turn on others.

@sbc100
Copy link
Member

sbc100 commented Apr 14, 2022

Sure, sounds like a useful flag to have. I wonder if it would make sense to call it --disable-all since I think that is what it would do?

@sbc100
Copy link
Member

sbc100 commented Apr 14, 2022

Either way seems reasonable to include.

@codefromthecrypt
Copy link
Author

almost, just that mutable-globals snuck into 1.0 :p

@sbc100
Copy link
Member

sbc100 commented Apr 14, 2022

I see. In that case we can probably simply remove the option to disable mutable globals.

@sbc100
Copy link
Member

sbc100 commented Apr 14, 2022

Perhaps --enable-X.X and --disable-all are both useful.

@codefromthecrypt
Copy link
Author

well yeah interesting.. as a runtime I think mutable globals are problematic and so it is helpful to disable them. --disable-all is 1.0 minus mutable globals and that's probably a better setting than --enable-1.0 for certain users.

PS --enable-X.X indeed.. there's probably a time to temporarily add --enable-1.1-snapshot for interop when things get that progressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants