Code completion at the top of non-empty maps in analysis_options.yaml and pubspec.yaml shows incorrect completions

[FMorschel]

Working as intented

If you have on analysis_options.yaml the following:

include: package:lints/recommended.yaml

linter:
  rules:
    - ^

analyzer:
  enable-experiment:
    - ^

On either ^ it will show you the possible rules for lints or possible experiments we have.

If you trigger auto-complete (CTRL + Space) on the left of the file, it will show you the sections; analyzer, linter, code-style, etc.

---

NOT Working as intended

If you do that with one indentation inside analyzer it still shows the same as the previous paragraph.

If you do that on ^ below:

analyzer:
  language:
    ^

Here is the output:

This is a mix of the possible entries for the analyzer section and the entire file-valid sections and (at the end because this is alphabetically sorted) the valid options for the analyzer.language section (strict-inference, strict-casts, etc).

---

Also, on another note, we can't do with the analyzer.language section what we can with the linter.rules section of posting them on a list. We need to add each one with : true (again, the auto-complete here is totally lost when it would show true/false options it shows a lot more).

---

Related to #57034.

[FMorschel]

FYI @srawlins @DanTup @bwilkerson

[DanTup]

Do you have a complete file sample that triggers this? When I try reproducing, I see this:

[DanTup]

Part of the difference might be due to me having "editor.wordBasedSuggestions": "off" off. By default, VS Code will add suggestions for all the words it finds in the document (I think this is poor behaviour myself). However, even with that enabled, the case above works correctly (but all the words from the document do show up in some other places).

[FMorschel]

Not on the same OS, will test it out later today on that same project. But there is still this problem with the parts for the analyzer scope:

---

Also,wordBasedSuggestions is set to off on Dart -> User

But I'm unsure of what it means. Would it only be set to off on .dart files?

[DanTup]

But I'm unsure of what it means. Would it only be set to off on .dart files?

Correct. I have it set to off in my VS Code User Settings so it's disabled for all languages, because IMO it's never useful. I think if you turned it off globally (or for YAML), you might be seeing empty results in the places where you see those (I think it might only appear as a fallback if the server doesn't return anything?).

I can reproduce this one:

[FMorschel]

Part of the difference might be due to me having "editor.wordBasedSuggestions": "off"

I`ve tested it again and I can confirm that was it.

I've also confirmed that the case you managed to repro above only happens if you already have one of the internal options for analyzer later.

If you trigger autocomplete after, it still thinks you're at the last spot:

See that there is no auto-complete option for true/false here and as I mentioned at the start, for some reason, this is not coherent with the linter->rules section where we can use a yaml list.

[DanTup]

I had a quick look at this thinking it'd be a trivial fix, but I don't think it is. The reason it fails is that in code like:

analyzer:
  ^

The AST for the file looks like {analyzer: null} and we return the null node which allows us to provide completion for the 1analyzer` section.

However, in the caseof:

analyzer:
  ^
  foo: bar

Here, the AST looks like { analyzer: { foo: bar } } and therefore there is no equivalent of the null node above, so we don't have a good node to base the completion on (we can't return analyzer, because completion for analyzer would still be the parent completions, which include analyzer but are not children of it).

So I think it'll need a little reworking of YamlCompletionResults._producerForPath so that we're not just trying to compute completion based on some node, but support producing completion for the children of a node (which probably also means representing this in some way in the path.. perhaps as a synthetic key?).

In the meantime, I did open a fix for the missing booleans for the strict- language options at https://dart-review.googlesource.com/c/sdk/+/409140 though.

[FMorschel]

Doing so would probably help with #57034, too.

Is your change enough for me to use the strict- language options as a list? Or is that something the team would like to avoid for some meaning @bwilkerson? I feel like these are close enough to how lints work today so they could be added as a list that would mean true for all.

[bwilkerson]

I believe that the medium to long term goal is to replace the language options with lints. I don't know what the time frame is for that, so I don't know whether it's worth the effort.

@srawlins

[DanTup]

Is your change enough for me to use the strict- language options as a list?

No, all I did was make the completion for the existing (map) entries provide boolean completions instead of no completions.

Since it just occurred to me, I'll also note the original issue described above also affects Pubspec (eg. you get "dependencies:" in completion here instead of package names):