Code completion ordering is wrong when autoImportCompletions is enabled

[maRci002]

• VSCode Version
  1.34.0

• OS Version:
  Windows 10

• Extensions:
  - Dart 3.0.2
  - Flutter 3.0.2

• Language
  Dart

My problem is that when a constructor (let's say new ListView.builder(...)) waits for specific type of arguments then the IDE should consider type matching while using autocomplete feature.

Here's a simplified example of this issue, the padding argument shoud implemet EdgeInsetsGeometry abstract class but autocomplete shows me random methods / keywords...:

I think the IDE is smart enough to know there are some classes which implement EdgeInsetsGeometry abstract class like: class EdgeInsets extends EdgeInsetsGeometry and should offer them as first results.

I don't know maybe the autocomplete results come from Dart analysis server and not related to VSCode at all. I tried to make some changes in the Settings.json but no success, even I tried the original recommended settings.

However in Android Studio everything works is fine, I hope this behavior can be implemented in VSCode too 👌

I would like to mention in Android Studio autocomplete is 2x times faster than in VSCode, but this is not related to this issue.

[DanTup]

The completions do come from the server, and it gives us some relevance that we're supposed to sort by. It seems likely we're not interpreting it correctly somewhere though, we should get the same results as Android Studio.

[maRci002]

So the analysis server suggests some sort relevance, I find this very cool and promising 🔥 🔥

I searched some old issues and found this one #1375, at that patch MaterialColor( (even Android Studio suggests the same because waiting for dart-lang/sdk#35587 issue) was fine suggestion for primarySwatch: so maybe it's an easy revert.

[DanTup]

Hmmm... I can't repro this - I get the results you want:

[DanTup]

Oh wait, I had auto-import-completions off... Got it now:

We must be calculating ranks wrong when using this new mechanism for completions (which supports auto-importing when you haven't already imported a file).

I'll take a look. Thanks!

[DanTup]

@bwilkerson @scheglov I'm not sure if there's a server issue here or if I'm misinterpreting the results..

Looking at my first screenshot above (using original completions), the EdgeInsets items appear at the top of the list (above context). However when using suggestion sets, here's the numbers I see:

AvailableSuggestionSets

EdgeInsets has tags of package:flutter/src/painting/edge_insets.dart::EdgeInsets,EdgeInsets
EdgeInsets.all has tags of undefined
EdgeInsets has tags of package:flutter/src/painting/edge_insets.dart::EdgeInsets,EdgeInsets
EdgeInsets.all has tags of undefined
EdgeInsets has tags of package:flutter/src/painting/edge_insets.dart::EdgeInsets,EdgeInsets
EdgeInsets.all has tags of undefined
EdgeInsets has tags of package:flutter/src/painting/edge_insets.dart::EdgeInsets,EdgeInsets
EdgeInsets.all has tags of undefined
EdgeInsets has tags of package:flutter/src/painting/edge_insets.dart::EdgeInsets,EdgeInsets
EdgeInsets.all has tags of undefined

Standard completions:

context has a relevance of 1059

Included SuggestionSets:

includedSuggestionRelevanceTags:
    package:flutter/src/painting/edge_insets.dart::EdgeInsetsGeometry = 10

Suggestion EdgeInsets.all from SuggestionSet ID:992
    Suggestion relevance tags: (none), suggestion set relevance: 7
Suggestion EdgeInsets.all from SuggestionSet ID:890
    Suggestion relevance tags: (none), suggestion set relevance: 4
Suggestion EdgeInsets.all from SuggestionSet ID:551
    Suggestion relevance tags: (none), suggestion set relevance: 4
Suggestion EdgeInsets.all from SuggestionSet ID:863
    Suggestion relevance tags: (none), suggestion set relevance: 4
Suggestion EdgeInsets.all from SuggestionSet ID:458
    Suggestion relevance tags: (none), suggestion set relevance: 7

So the EdgeInsets class gets tags of "package:flutter/src/painting/edge_insets.dart::EdgeInsets,EdgeInsets" (which doesn't include the tags of its abstract base (package:flutter/src/painting/edge_insets.dart::EdgeInsetsGeometry) which comes in the includedSuggestionRelevanceTags), and the values (for ex .all) don't get any tags at all.

As such, everything just gets its included relevance (4 and 7) which is way lower than the 1059 assigned to context, so they appear further down.

The things that seem wrong are:

• EdgeInsets doesn't include EdgeInsetsGeometry in its tags
• EdgeInsets.all doesn't include any tags
• Even if the tags had matched up, the relevance of 10 is way off 1059 so it'd never end up above context?

Strangely, I can't repro in Android Studio (though admittedly, I don't know how to confirm it's using suggestion sets).

Is there something I'm overlooking of misinterpreting?

[scheglov]

Relevance is one of the victims of this auto-imports.
We tried to alleviate this, but only to some extent.

• We compute available suggestions using only parsed AST, so we don't know that EdgeInsets implements EdgeInsetsGeometry.
• I will look at constructors and their tags.
• Tags for top-level declarations are intended to to establish order among top-level declarations. So, yes, relevances of top-level declarations and local elements are not comparable.

[DanTup]

We compute available suggestions using only parsed AST, so we don't know that EdgeInsets implements EdgeInsetsGeometry.

Ah, I see :( Is there any way around this? (for ex, could we use "the old way" for files that are already imported?)

relevances of top-level declarations and local elements are not comparable.

I'm not sure what to do here.. How should the items be sorted by the client?

I may have found why it looks ok in Android Studio, the release notes say the suggestionsets work isn't supported there yet (only IntelliJ - though I don't have that installed to check there currently).

[scheglov]

I don't have a good solution for this.

Using the old way for already imported libraries is not really an option, in case of Flutter this is a lot of suggestions to send from DAS.

When a tag from an AvailableSuggestion matches a tag in includedSuggestionRelevanceTags, it is up to the client to prioritize. I think making it a "top relevance" might work. These tags, at least now, are type based. So, if something expects type String, we would suggest top-level variables of type String higher than of type int.

[DanTup]

In that case, couldn't we just crank the relevance in those tags up to be higher than the normal relevances (eg. add 10000 to them)?

For LSP, we can't have any logic "on the client", so the server will need logic on how to handle this anyway (which makes me think it may be better to "fix" it in the server for all?).