Quick Fixes for Class Modifier Diagnostics

[pq]

[bwilkerson]

There's only one diagnostic so far: CompileTimeErrorCode.INVALID_USE_OF_TYPE_OUTSIDE_LIBRARY (though there are 9 variations on the message for the sake of clarity).

Without knowing the specific semantics the user is trying to achieve, the only fixes I can think of are to

• change the type being used to one that's valid,
• remove the use of the type, or
• change the type being used so that its use is valid (add or remove a modifier).

I don't know how common any of those fixes are likely to be, so I don't know how useful any of these fixes would be to automate.

For the first, we have a fix that will look for similarly named types, though it doesn't know about the capability modifiers, so it might suggest a different class that's equally inappropriate. That limitation should be fixed for other reasons, even if we don't apply that fix here.

For the second, we could obviously remove the code.

For the third, we could update the modifiers appropriately (when the declaration of the type is in a file that's explicitly being analyzed), though there are likely to be a lot of cases to consider.

@kallentu In case you have ideas on this topic, including other diagnostics that still need to be added.

[eernstg]

Change the usage, if possible? (so extends C becomes implements ..., C if C is interface, and so on)

[bwilkerson]

Definitely an interesting possibility, thanks. I'm not sure how often those would be useful either, but then I don't know much about how best to help users around these errors.

[pq]

A fix to add @reopen when an implicit reopen (#58976) is desired seems reasonable.

[bwilkerson]

Agreed. I wasn't thinking about the lint that hasn't been added yet, just the existing diagnostics. :-)

[kallentu]

There's CLASS_USED_AS_MIXIN whose quick fix could be adding a mixin modifier.

And there will be another error diagnostic for the part of the spec that specifies A subtype of a base or final class must be base, final or sealed. but I have not added this yet. Perhaps the quick fix for this would be to add a base or final depending on the supertype's modifier. Not sure if that's the best heuristic, but I think we could potentially do something here?

Also, for what currently is MIXIN_INHERITS_FROM_NOT_OBJECT and MIXIN_CLASS_DECLARES_CONSTRUCTOR (which after talking to @bwilkerson, I'll make another one for Dart 3 to separate when the error occurs between old versions and >3) -- we can make a fix that removes the inheriting or removes the constructor respectively.

For INVALID_USE_OF_TYPE_OUTSIDE_LIBRARY, I was talking about this briefly with @pq yesterday and I couldn't figure out a good quick fix. You can't remove the modifier from the class declaring it, because it seems like that's the intention of the author to add a restricting modifier, otherwise they would've left it as class. I also don't know how useful changing the type of inheritance (extends to implements for example) would be. Removing the subtyping relation would be okay.

[bwilkerson]

We didn't create issues or even a check list for any of these ideas. Do we know of any fixes that would be particularly valuable?

[kallentu]

MIXIN_CLASS_DECLARATION_EXTENDS_NOT_OBJECT -- removing the extends __ or with __.
CLASS_USED_AS_MIXIN -- adding a mixin modifier
SUBTYPE_OF_BASE_IS_NOT_BASE_FINAL_OR_SEALED -- add base onto the erroneous subtype
SUBTYPE_OF_FINAL_IS_NOT_BASE_FINAL_OR_SEALED -- add final onto the erroneous subtype

Maybe these ones are low hanging fruit?

Although, people will encounter INVALID_USE_OF_TYPE_OUTSIDE_LIBRARY the most probably.