Some errors on creating getter/setters/mixin at record field

[FMorschel]

Repro:

extension on int {
  (bool, bool, {int v, int v2}) get record => (
    myBool,
    myBool2(),
    v: v,
    v2: v2(),
  );
}

Results:

• On stable, we get Create getter but not on master
• The generated getter/method doesn't calculate the expected return type
• At the non-invocation cases, we also get a Create mixin

I'll take a look into this.

[FMorschel]

Here is the CL https://dart-review.googlesource.com/c/sdk/+/432580

[FMorschel]

FYI @kallentu the above CL works with all of the create method options we currently have if you want to use it as a reference.

[FMorschel]

@srawlins and @bwilkerson, I've rebased this CL yet again. Can I get some reviews there, please? Thanks a lot!

[bwilkerson]

In reviewing the CL I came up with a question about the semantics of the fix. Consider the following code:

class A {}
class B extends A {}
class C extends B {}

extension AE on A {}
extension BE on B {}

void f(C c) {
  c.g;
}

Should the fix create the method in BE, or should it create a new extension on C? I'm currently leaning toward having it create a new extension when there isn't an existing extension whose type matches exactly. I think that's probably true for the case where the target type is nullable but the extension is on a non-nullable type:

class A {}

extension on A {}

void f(A? a) {
  a.g;
}

but not when the target type is non-nullable and the extension is on a nullable type:

class A {}

extension on A? {}

void f(A a) {
  a.g;
}

What do you think?

[FMorschel]

Great thinking! I like that very much.

Since the analyzer will always look for the most specific extension it can find, I'd say this behaviour would be best aligned with that one. I'll add those tests and implement this. Thanks!

[FMorschel]

I've done some initial changes and run to see what other tests would fail, and tests with generics fail... Things like:

void f(List<int> a) {
  a.test = 0;
}

extension E<T> on Iterable<T> {}

Which would add the setter inside the existing extension. I'm not yet sure how I feel about that, or the following changing the behaviour for new extensions:

void f(List<int> a) {
  a.test();
}

extension E<T extends Iterable<int>> on T {}

Any takes here? I could try and create a smart workaround, but I'd like for that rule to make some sense as a whole.

[FMorschel]

Okay, after some thought, I think I've managed to make a rule that makes some sense.

If the type is the exact type or if the type is valid and the extended type is or uses type parameters. I'll wrap this up and push a new patchset.

[bwilkerson]

For the example of

void f(List<int> a) {
  a.test = 0;
}

extension E<T> on Iterable<T> {}

It seems reasonable to me for it to create a new extension. The new setter might not apply to all Iterables, nor to lists of any type other than int.

The same logic applies to the second case. The extension method would be on a more general type than the one on which it's being invoked and that might not make any sense.

I suspect that there will be some confusion either way we go, but I suspect it will be easier for users to see the need to move the extension method to a more general type if they try to use it on a non-List subclass of Iterator than it would be to realize that their implementation of the method is restricted because of adding it for a more general type and needs to be moved to a new extension.

[FMorschel]

I've uploaded a new patchset with the requested changes.