[kevingadd]

It's not really a matter of prioritization. The current WASM platform and toolchain are missing features necessary for AOT-compiling things like .NET executables. For one example, exception filters ... and unfortunately the standard library uses them, not to mention end-user software.

To provide more detail: Exception filters require the ability to stackwalk and search for filters and run them before actually handling the exception. WASM has no stack-walking functionality whatsoever (this also means getting and introspecting stack traces is currently impossible), so searching for filters is already a non-starter. You can try and emulate this through a normal unwind-only exception flow, but you have to rewrite all your application code to insert lots of checks and flow control changes in order to do it, and it's still observably different.

I've spent months just working on fixing this problem, and it's one of the things that wasm AOT is going to need before it can ship.

WASM is a generally weak target platform. A great 1.0, to be sure, but unless your goal is to run posix C code you're going to hit snags. When we were designing WebAssembly to begin with it was an intentional decision for 1.0 to be limited in feature set with the goal of improving it later - a Minimum Viable Product.

[GordonS]

Sorry for any confusion caused on my part - my gripe wasn't with compilation to WASM, but about AOT to native bytecode.

[kevingadd]

Exception filters are also a problem for AOT to non-WASM LLVM targets, for similar reasons - expressing complex exception handling and flow control in LLVM is very difficult. But the situation is better there, at least.