Dart2Wasm implementation limitations

[askeksa]

The Wasm backend has some limitations compared to the full Dart spec due to inherent limitations in Wasm.

This issue is for:

• Documenting these limitations
• Discussing issues related to the limitations, e.g. how to report them to the user, whether workarounds are needed in some cases, where else to document them, etc.
• Marking test failures and skipped tests related to the limitations

The currently known limitations are:

• Functions can have at most 1000 parameters (including special parameters such as receiver and type parameters), due to the Wasm limitation of 1000 parameters for functions.
• Function objects can have at most 60 positional parameters, due to function types being represented as a hierarchy of structs with one level per maximum number of positional parameters, combined with the Wasm maximum subtype depth of 63. The number of named parameters is not similarly limited.
  • This can potentially be optimized to limit the number of different maximum numbers of positional parameters occurring in the program instead.
• The maximum nesting depth of subclasses, including applied mixins, can be at most 63, due to the Wasm maximum subtype depth of 63. The nesting depth of interfaces is not limited.
  • This can potentially be optimized to not include mixin application classes.
• Stack overflow causes a Wasm trap instead of throwing an exception, since stack overflow can't be caught in Wasm.

[parlough]

\cc @MaryaBelanger Just so this is in the back of your mind.

From a website documentation perspective, outside of the lack of a stack overflow exception, the others sound quite rare or specific. As a result, I imagine rather than documenting them with special notes when discussing that functionality (like we do with some other platform limitations), they can likely be constrained to a page discussing dart2wasm specifically. Also, we will need to adjust how we discuss the number limitations on the web platform, or actually lack of those limitations for the dart2wasm compiler.

From a general perspective, it seems these limitations could be reported by one or more new lints, so package developers not testing against the dart2wasm compiler can more easily catch (and learn about) those limitations, despite their rarity.