1819215 - Implement function subtyping

Status: VERIFIED FIXED

(Core :: JavaScript: WebAssembly, task, P3)

Description

[Kevin Moore]

Steps to reproduce:

Load https://flutterweb-wasm.web.app

Enable wasm_gc, wasm_function_references

Actual results:

App does not load. Dev console: Failed to fetch and instantiate wasm module: CompileError: wasm validation error: at offset 46036: incompatible super type

Expected results:

App runs like it does in Chrome.

Comment 1

[Kevin Moore]

Note from engineer on my team:

If the issue is what I think it is, it's probably that their supertype validation for functions needs to have covariant return types and contravariant arguments

And I'm guessing right now it's strict equality

Also: it seems like without JSPI, things won't work either. But if this helps get us closer, awesome!

Comment 2

[Kevin Moore]

Another comment from an engineer: https://github.com/mozilla/gecko-dev/blob/b9090fc59fcc56c32c56fae1b53a8db0818ab1b3/js/src/wasm/WasmTypeDef.h#L190

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript: WebAssembly' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Igor Iakovlev]

Seems we are (in Kotlin-Wasm) facing similar issue with code optimised with Binaryen.
V8 works fine.
Supertype hierarchy looks ok but got "incompatible super type".

Sample wasm file:
https://drive.google.com/file/d/1NVIYKl5_wa3TYD82ryEPR5t1AwFsDUDO/view

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:rhunt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Ryan Hunt [:rhunt]]

Yes, we currently have a limitation that func types must be strictly equal. This was arbitrary though and we should be able to relax it.

Comment 7

[Julien Pages [:jpages]]

I have a patch in local which fixes this particular issue.
However, several other problems appear after that:

With this example https://flutterweb-wasm.web.app:
After fixing the subtyping issue, the error is now "CompileError: wasm validation error: at offset 1515444: unrecognized opcode: fb 41"

This opcode looks to be defined in some GC-proposal extensions, uses opcode that we are not supporting for now (0xfb41)
Reference is here https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md#instructions-1

With the kotlin-wasm example, there was this subtyping issue "incompatible super type" which is fixable indeed.
After the fix, I had this error: wasm validation error: bad type 0x65

This opcode is not supported now but should be after this is implemented https://bugzilla.mozilla.org/show_bug.cgi?id=1827952

I could bypass that with the WIP patch but then I'm having an error: uncaught exception: [object WebAssembly.Exception]

Comment 8

[Julien Pages [:jpages]]

Attachment: WIP: Bug 1819215 - wasm: Add a debug function for TypeDef.

Comment 9

[Julien Pages [:jpages]]

Attachment: Bug 1819215 - wasm: Change subtyping rules for functions. r=rhunt,jseward

Previously, function subtyping was only checking the invariance.
Now, return types are covariant and arguments are contravariant.

Depends on D175696

Comment 10

[Julien Pages [:jpages]]

Attachment: Bug 1819215 - wasm: Change the validation of supertypes during parsing. r=rhunt,jseward

Depends on D175697

Comment 11

[Kevin Moore]

(In reply to Julien Pages [:jpages] from comment #7)

I have a patch in local which fixes this particular issue.
However, several other problems appear after that:

With this example https://flutterweb-wasm.web.app:
After fixing the subtyping issue, the error is now "CompileError: wasm validation error: at offset 1515444: unrecognized opcode: fb 41"

This opcode looks to be defined in some GC-proposal extensions, uses opcode that we are not supporting for now (0xfb41)
Reference is here https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md#instructions-1

With the kotlin-wasm example, there was this subtyping issue "incompatible super type" which is fixable indeed.
After the fix, I had this error: wasm validation error: bad type 0x65

This opcode is not supported now but should be after this is implemented https://bugzilla.mozilla.org/show_bug.cgi?id=1827952

I could bypass that with the WIP patch but then I'm having an error: uncaught exception: [object WebAssembly.Exception]

FYI: we still use JSPI – I wonder if that's what you're hitting.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/acd6ebbf770c
wasm: Change subtyping rules for functions. r=rhunt

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c49f35eb0846
wasm: Change the validation of supertypes during parsing. r=rhunt,jseward

Comment 14

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/acd6ebbf770c
https://hg.mozilla.org/mozilla-central/rev/c49f35eb0846

Comment 15

[Julien Pages [:jpages]]

Many patches related to wasm-gc have landed recently, the original error "CompileError: wasm validation error: at offset 46036: incompatible super type" is now fixed.

However, this app https://flutterweb-wasm.web.app still doesn't load. It's not the same error but this is probably related to JSPI: "second argument must be a function". We are planning to implement JSPI in wasm in the future but for now it's not supported. Maybe try without JSPI if possible to see if it loads?

For the Kotlin-wasm issue, the original error is fixed but I'm still getting an uncaught Exception even with all the patches: uncaught exception: [object WebAssembly.Exception]

I'll follow up in this ticket for the exception problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1820163

Comment 16

[Kevin Moore]

Confirming we (Flutter/Dart Wasm) are using JSPI. Working to remove now. Thanks for your work here!

Comment 17

[Kevin Moore]

FYI: https://flutterweb-wasm.web.app/ now works with Firefox nightly + flags. Thanks for your work here!