[Extension type] DDC implementation

[itsjustkevin]

No description provided.

[eernstg]

Please note that this feature has been renamed: It is now the 'inline class' feature.

[nshahan]

Open question: Is it useful for DDC to see ExtensionType nodes in the AST or can they be erased sometime before compilation begins? Are they necessary for the production of JS interop errors?

[sigmundch]

I believe it is useful. @srujzs can share more, but I believe the _js_interop_checker and transformation that runs from DDC and dart2js needs to see the extension classes to properly do its work. That said, during code emission performing the erasure should be simple in that the CFE already provides the erasure semantics as properties on the extension type (e.g. DDC can read the internal .erasedType and emit that instead.)

@annagrin - may also have some insights from the debugging perspective. There may be some metadata that we may need to include in the future to integrate with devtools.

[srujzs]

Nick and I chatted offline shortly after - we indeed do need to see ExtensionTypes in the AST to make some of our interop checks work. Our takeaway was that there is a small tax, however, from handling these types in every visitor (and not handling it is not necessarily an error). In DDC's case, there are some explicit conditionals checking for types too (and emitting an "invalid" type if not handled), so this lead to some hidden errors. Still, this can be handled by just calling typeErasure and more generally, these issues can be fixed by improving how we visit types as well.

I think the open question then is whether there's a way to have the JS interop checks still see nodes related to extension types, but have DDC use a lowering that removes them from the AST.