Track the ExtensionTypeElement associated with constant DartObjects.

[mattrberry]

I'd like to propose a feature that would allow users of the analyzer to work back to the extension type for a DartObject, similar to what was done with VariableElement.

This will give lints and code generators a little bit of visibility into how an object is constructed and its type.

The particular limitation I'm seeing now is when an extension type is defined over a private type. For a reduced and contrived example, take

class _Foo {
  const _Foo();
}
extension type const Foo._(_Foo _) implements _Foo {
  const Foo() : this._(const _Foo());
}

In this case, the lint or code generator might want to do something with the static type Foo. Today, the analyzer believes that the type of const Foo() is a _Foo which is true at runtime, but doesn't allow much further. A lint or generator might want to understand what a Foo is, even if it won't exist at runtime. The lint or generator sometimes can't even tell that the object is an extension type, let alone what the extension is.

For an example with Mockito, see

@GenerateNiceMocks([MockSpec<Foo>()])

which produces the error

Invalid @GenerateMocks annotation: Mockito cannot mock a private type: '_Foo'.

(FWIW this might be a bad example, but it's one of the cases that breaks with my real use-case for the contrived example above. Maybe Mockito itself could be updated to handle this case, I'm not sure.) I have been looking at supporting this for Angular, though, where an app might want to provide an instance of Foo, but the framework can't figure out how to produce code for that because all it sees is _Foo.

I'll conclude here rather than let this get too rambly :) Please let me know if there are cases I'm not accounting for regarding why this couldn't or shouldn't be implemented! If there's just a bandwidth issue, I'm happy to look into it myself because it's potentially limiting some other high impact work. Thanks!

[bwilkerson]

@scheglov