Implementation Issue for SuperMixins: CFE / Kernel

[JekCharlsonYu]

What: Issue for implementation for CFE/Kernel

ETA: 10/15 in Dart Repo.

For: SuperMixins Implementation and strawman documentation

Meta Issue: This is subsumed under the Super Mixins Meta Issue in the Language Repo

Comments: Feel free to break this further into further tasks and issues, or use as a meta issue for all the tasks in the implementation plan

[danrubel]

Parsing, events, parse errors, recovery, and AstBuilder mods are now complete.

[leafpetersen]

CL out with tests for mixin inference here: https://dart-review.googlesource.com/c/sdk/+/74017

[leafpetersen]

Inference tests have landed.

https://dart-review.googlesource.com/c/sdk/+/74017

mixin_declaration/mixin_declaration_inference_valid_classes_test is failing and in some cases crashing.

[kmillikin]

Support for compiling mixins has landed. The static checks required at mixin applications are not yet implemented.

There are two kinds of checks on the class that the mixin is applied to: (1) that it implements the superclass constraint interfaces and (2) that it provides concrete implementations of the methods that are used in super calls in the mixin.

The first of these is straightforward to implement and can be done soon. The second of them is of moderate difficulty.

[leafpetersen]

Presumably code that doesn't satisfy 2) is already broken, and can only "work" if the code is not exercised? Based on that, I'd prioritize 1) and consider letting 2) slip if necessary.

[kmillikin]

Code that doesn't satisfy (2) -- that the superclass provides implementations of the required superclass methods -- is broken.

Checks for (1) -- that the supertype implements all the constraint interfaces -- is implemented in https://dart-review.googlesource.com/c/sdk/+/79206, landing as soon as I verify that it doesn't break dart2js.

[kmillikin]

To elaborate on mixins that contain super calls which are applied to classes that don't have implementations of those methods: either the mixin and the subclasses of the mixin application do not implement the method, in which case it is a compile-time error to instantiate it because the classes are abstract; or else the method is implemented in the mixin or a subclass of the application but it would be a runtime error to evaluate the super call in the mixin.

I also just discovered that the VM allows one to extend a mixin (and class C extends M means class C extends Object with M). I will work on statically disallowing that right now.

[kmillikin]

CFE now signals an error when a class extends a mixin (implemented here).

[dgrove]

What remains here?

[kmillikin]

As far as the feature goes: we are missing static checks at mixin applications that the superclass has implementations of the methods that are used in super calls in the mixin declaration. Unfortunately, I think these have to get on the next release.

We also want to do some internal cleanup soon (e.g., represent mixins directly in Kernel), but that isn't tied to any particular release.

[dgrove]

Can this be closed?

[kmillikin]

Yes.