Add more accurate/specific BCD for Wasm mutable globals

[chrisdavidmills]

Summary

As part of my mission to document all the missing Wasm features, I am working on making sure Wasm mutable globals are properly documented. We previously had a webassembly.mutable-globals data point, but this was just describing the overall feature itself, rather than the specific parts of the tech that comprise the feature. And it was only used to show a BCD table on the WebAssembly main landing page — having this many BCD tables on the same page is not a great user experience, so I have decided to start removing them and showing the information elsewhere.

I have updated the BCD to get rid of that, and:

• Add a specific subfeature for the mutable option of the WebAssembly.Global() constructor.
• Add separate data points for the global, global.get, and global.set Wasm text format instructions. I've put these in an instructions directory, and I could also see us adding further directories for definitions, types, etc.

This is not ready to merge yet. The main outstanding issues are as follows, which I am hoping @eqrion and colleagues can weigh in here and advise, as well as the BCD folks:

• I have no idea if the browser support versions are correct. For now, I've just copied the mutable_globals support versions. I'm not really sure how to find all this information (for Wasm instructions in general, not just these few instructions) without it being hugely time-consuming. Any thoughts?
• We need to get agreement on whether this kind of structure is appropriate and will work for Wasm?

Test results and supporting details

Related issues

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[eqrion]

Wasm 1.0 shipped in Firefox 55, Chrome 57, and Safari 11. You can use those version numbers for any instruction/definition that wasn't in a wasm proposal.

I also double checked the versions for the mutable globals proposal.

[1] https://www.firefox.com/en-US/firefox/52.0/releasenotes/?redirect_source=mozilla-org
[2] https://chromestatus.com/feature/5453022515691520
[3] https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_0.html

[eqrion]

For wasm proposals, feature status is where browsers announce their support for a proposal.

[eqrion]

We need to get agreement on whether this kind of structure is appropriate and will work for Wasm?

I don't know much about how browser compat data works. The data in this PR seems reasonable, but also probably very repetitive? It'd be nice to automate or simplify it so it doesn't need to be per-function or per-definition.

[chrisdavidmills]

The linter is currently failing because it doesn't recognise https://webassembly.github.io/spec/core/ as a valid spec. I've requested it be added in w3c/browser-specs#2449.

[chrisdavidmills]

For wasm proposals, feature status is where browsers announce their support for a proposal.

Ah ha, this is really useful.

[chrisdavidmills]

We need to get agreement on whether this kind of structure is appropriate and will work for Wasm?

I don't know much about how browser compat data works. The data in this PR seems reasonable, but also probably very repetitive? It'd be nice to automate or simplify it so it doesn't need to be per-function or per-definition.

Generally, what we do is record browser compat data as granularly as possible. This has many advantages in terms of flexibility:

• You can refer to individual features, or group them to provide an overall sentiment of support for an entire spec or API, which is what we do with the baseline project
• If a bug is found with a particular feature, or a new option (or whatever) is introduced, we can easily add that.
• Generally, it is rare that an entire spec or featureset will have exactly the same browser support, so we need to be able to expose those differences.

So yes, it is pretty repetitive, but we can use a script to generate lots of BCD support files pretty quickly, provided the support data is the same. This is what I'm intending to do for the SIMD stuff I've just added. I'm assuming all the fixed-width SIMD instructions were supported at the same time (in the versions referred to on https://webassembly.org/features/?categories=browsers)?

[chrisdavidmills]

The linter is currently failing because it doesn't recognise https://webassembly.github.io/spec/core/ as a valid spec. I've requested it be added in w3c/browser-specs#2449.

OK, scratch that. The bikeshed version of the spec is already in the system, so I'm using that instead. It is more searchable than the other version anyway.

[eqrion]

So yes, it is pretty repetitive, but we can use a script to generate lots of BCD support files pretty quickly, provided the support data is the same. This is what I'm intending to do for the SIMD stuff I've just added. I'm assuming all the fixed-width SIMD instructions were supported at the same time (in the versions referred to on https://webassembly.org/features/?categories=browsers)?

Yes, all the fixed-width SIMD stuff was added in the same version. AFAIK, every wasm proposal has shipped as a unit in the same release. There may be some odd exceptions for a bug like you say, but I'd assume by default everything shipped together.