Ryan Hunt

> Wait, that is what Cfg::Named is for, no? Ah yes you're correct. My memory failed me a bit there.

> > 1. The [representation of `ValType`](https://github.com/bytecodealliance/wasm-tools/pull/701#discussion_r940519444) uses some `#[repr(packed)]` tricks to be 4-bytes but this means that you can't have more than 65k function types in a module. Currently...

June works well for me. Slight preference to avoid June 7th, but I think we usually do a midweek thing which wouldn't conflict with that.

> I think we should avoid clashing with TC39 if possible - we want to encourage some cross-committee attendance especially if threads is discussed. > > @ashleynh does June 4-6...

Mozilla has an all-hands meeting Aug 13-15, so that would not work well for me. Those other dates in Jul work though. I have no strong preference either way.

This sounds good to me. I just filed an issue [here](https://github.com/WebAssembly/relaxed-simd/issues/150) to discuss the future scope of the `deterministic` profile introduced in relaxed-simd. I would like to have that resolved...

That is my understanding of WebAssembly.Global behavior. It's implied by the behavior of DefaultValue [1]. The Table JS-API methods also have this behavior as well. [1] https://webassembly.github.io/spec/js-api/index.html#defaultvalue

There's also a test case here for default JS-API values for globals: ``` const global = new WebAssembly.Global({value: "externref", mutable: true}); assert_equals(global.value, ???); ``` My reading of the JS-API spec...

I think I touched it just to tweak error reporting. We don't use this script anymore though and have a custom way we run the spec tests in SM.

> There is one open question with these tests, which is that all the error cases are assumed to throw a `WebAssembly.LinkError`. However, I believe the current spec actually mandates...