Auto completion of dot-shorthands missing cases

[FMorschel]

Repro:

enum E { a, b }

void foo(E e) {
  int _ = switch (e) {
    .a => 1,
    .^
  };
}

FYI @kallentu @bwilkerson

I'll take a look at this one.

[FMorschel]

There is also this case:

void foo(E e) {
  A(.^); // Completion works
  B(.^); // Completion works
}

class A {
  A(this.e);
  final E e;
}

class B extends A{
  B(super.e);
}

class C extends A {
  C() : super(.^);  // Missing completion
}

[incendial]

This is probably related, but this also does not have autocompletion:

void withEnum() {
  final MyEnum? nullable = MyEnum.first;
  if (nullable == MyEnum.first && nullable == /* try typing .first here */ ) {}
}

enum MyEnum { first, second, third }

Edit: though I'm on Dart SDK version: 3.9.2 (stable) (Wed Aug 27 03:49:40 2025 -0700) on "macos_arm64"

[FMorschel]

I suspect so, too. I've tested on main from two days ago, and this is the output from your case:

It is probably getting the value from the bool operator ==(Object other). I'm not sure. What would you say should happen here, @bwilkerson? I mean, should this get special-cased? When we try using dot-shorthands in ==.

[FMorschel]

Even weirder is the result when you select .new():

[FMorschel]

Yes, I think we missed a few places. I also just tested:

enum E { a, b }

void foo(E e) {
  switch (e) {
    case .a:
      return;
    case .^
  }
}

No completion at the ^.

[bwilkerson]

I mean, should this get special-cased? When we try using dot-shorthands in ==.

I don't think we need to special-case ==; it ought to work like any other operator, taking the parameter's type as the context type.

Even weirder is the result when you select .new():

I don't know why we're suggesting new at all. Nor do I understand how it's deciding that the dot-shorthand is referring to a constructor on an enum.

@kallentu @scheglov Can either of you help me understand why the context type appears to be MyEnum?

(And the message is terrible. The user probably knows that generative constructors are used to create new instances, the point is that you can't do that outside the declaration of the constants.)

[incendial]

It also does not make sense that there are suggestions for hash() and friends as they are not suggested in other cases with enums:

[FMorschel]

(And the message is terrible. The user probably knows that generative constructors are used to create new instances, the point is that you can't do that outside the declaration of the constants.)

I fixed #61680 recently, but only for tearoffs.

It also does not make sense that there are suggestions for hash() and friends as they are not suggested in other cases with enums:

These are other top-level things on Object.

Nor do I understand how it's deciding that the dot-shorthand is referring to a constructor on an enum.

I'm not sure, but if, when resolved, it is considered the enum constructor, this would need to be special-cased IMO. To match the resulting parse.

[scheglov]

@kallentu @scheglov Can either of you help me understand why the context type appears to be MyEnum?

It is not MyEnum, but Object. Although I'd expect it to be effectively MyEnum, most probably we want to compare values.

Test in ContextTypeTest

  Future<void> solo_test_binaryExpression_RHS_XXX() async {
    await assertContextType('''
void withEnum() {
  final MyEnum? nullable = MyEnum.first;
  if (nullable == MyEnum.first && nullable == .^ ) {}
}

enum MyEnum { first, second, third }
''', 'Object');
  }

[bwilkerson]

It is not MyEnum, but Object.

Which would explain the hash suggestions, since they're static members on Object.

But it doesn't explain the diagnostic. If .new() is resolved with a context type of Object then it shouldn't be complaining about an enum constructor.

Although I'd expect it to be effectively MyEnum, most probably we want to compare values.

Only if we're special casing ==. Otherwise we should be using the type of the parameter to ==, which is Object.

Are we special casing it in some places and not in others?

[scheglov]

It is not MyEnum, but Object.

Which would explain the hash suggestions, since they're static members on Object.

But it doesn't explain the diagnostic. If .new() is resolved with a context type of Object then it shouldn't be complaining about an enum constructor.

We probably talk about two different context types here: resolution vs. completion.
My test above was about completion.

Although I'd expect it to be effectively MyEnum, most probably we want to compare values.

Only if we're special casing ==. Otherwise we should be using the type of the parameter to ==, which is Object.

Are we special casing it in some places and not in others?

For resolution, yes.
https://github.com/dart-lang/language/blob/main/accepted/3.10/dot-shorthands/feature-specification.md#special-case-for-

[kallentu]

As Konstantin linked, == is special-cased so that we take the static type of the LHS to use as the context type for resolving the RHS. From what I'm seeing from the issue, I missed implementing the completion for this (and super calls, switch cases).

The correct context type for the above examples (nullable == .^) should be MyEnum. But I think the implementation isn't there, so it's using Object.