Improve auto-complete for override

[FMorschel]

If you type @override and ask for auto-completion, this is the output sample:

When you continue writing value, VS Code filters it client-side:

But if you close that auto-complete and come back, these are the outputs:

• Asking for auto-complete after override and before value:

• Asking for auto-complete after it all:

I'd like to request that the two last examples work the same as the second image.

CC @DanTup

[scheglov]

Good idea.

If possible, please also take into account what IntelliJ would do, and if any changes are required there too.

[bwilkerson]

The "problem" here is that our code completion is based on the semantics of the code rather than the lexical qualities of the code, but the filtering, as you noted, is based on the lexical qualities.

When you complete after @override the identifier has been resolved to an existing element, so our code completion engine knows that you're completing an override annotation and guesses that you might want help inserting an override of some inherited member. VS Code does filtering based on text, so the lack of a space is ignored in that process.

But when you complete after @overridevalue, it sees that you're trying to complete a name that starts with overridevalue, and can't find any names matching that pattern. It doesn't try inserting a space into the name to see whether it can find a known name that you might have meant. The same is true when completing in the middle of overridevalue, it just changes the prefix used by the completion engine to filter the results such that a few suggestions show up.

We could, potentially, special case override by checking whether the identifier starts with override, but I'm not sure how much value that adds across our users.

As a work around, I'll note that if you start typing the name of the inherited member (without the @override) it will also provide suggestions for overriding the inherited member, and that form has (or should have, I haven't tested it) the ability to correctly resume the operation if the cursor is moved during the process.

[FMorschel]

or should have, I haven't tested it

It doesn't apparently, only if you continue writing (removing/adding characters - second recording):

20250117_155132.mp4

20250117_155641.mp4

About IntelliJ, it does have the same behaviour I mentioned above as vscode. But I can't seem to enable the same auto-complete for overriding when writing down the member name:

20250117_155549.mp4

So it seems that at least right now, for IntelliJ users this @override special-casing would be helpful.

[scheglov]

I think special casing (in DAS, VS Code, and IntelliJ) @overrideXYZ is totally reasonable. This will provide a useful feature for our user, and chances of false positives don't look too bad. Currently @over, without complete @override and without anything after full @override, is already special cased in DAS.

[bwilkerson]

It doesn't apparently, only if you continue writing ...

That sounds like a bug.

But I can't seem to enable the same auto-complete for overriding when writing down the member name:

That also sounds like a bug.

Currently @over, without complete @override and without anything after full @override, is already special cased in DAS.

What's special cased, iirc, is the override element from dart:core, not the text.

Personally, I'd much rather see us support @override va^ as a way to get these suggestions than to support @overrideva. I think it would be much more discoverable and hence more useful.

[FMorschel]

Personally, I'd much rather see us support @override va^ as a way to get these suggestions than to support @overrideva. I think it would be much more discoverable and hence more useful.

If that is at all possible I agree it'd be better.

Should I file other issues for the above or can we use this to track that work too?

[bwilkerson]

I think we can use this issue for all of the 'override' related bugs. If it gets too confusing we can try out the new sub-issue feature.

[FMorschel]

Something else I've noticed, not sure what is the problem here, but it seems to ignore one-letter auto-complete options here:

But the interesting part is that when I leave (close) this auto-complete and simply add an a after the r, it shows only random. Probably the same bug we saw above on value not showing up when it was fully written.

[DanTup]

I had a quick look at the issue with exact matches not showing up. This appears to be because of what's described here:

sdk/pkg/analysis_server/lib/src/services/completion/dart/override_helper.dart

Lines 92 to 100 in c19f913

	// TODO(brianwilkerson): When the user is typing the name of an
	// inherited member, the map will contain a key matching the current
	// prefix. If the name is the only thing typed (that is, the field
	// declaration consists of a single identifier), and that identifier
	// matches the name of an overridden member, then the override should
	// still be suggested.
	if (!interface.declared2.containsKey(name)) {
	namesToOverride.add(name);
	}

When you have typed the complete name (r in the example above), that class now has r in it's declaration, so the completion code doesn't include r because it thinks it already exists. The condition following that comment needs to account for this (however it's not clear to me how to determine this from the Element model, and perhaps that's why it's outstanding).

Some example LSP tests for this (test/lsp/completion_dart_test.dart), one passing (_partial) one failing (_complete) are:

  @soloTest
  Future<void> test_local_override_complete() async {
    var content = '''
abstract class A {
  int? get value;
}

class B extends A {
  value^
}
''';
    await expectLabel(
      content,
      label: 'override value',
      labelDetail: ' int? get',
      labelDescription: null,
      filterText: 'value',
      detail: 'int? get',
    );
  }

    @soloTest
  Future<void> test_local_override_partial() async {
    var content = '''
abstract class A {
  int? get value;
}

class B extends A {
  val^
}
''';
    await expectLabel(
      content,
      label: 'override value',
      labelDetail: ' int? get',
      labelDescription: null,
      filterText: 'value',
      detail: 'int? get',
    );
  }