You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pubspec doesn't populate the available versions anymore #3731
I can reproduce the same though - it shows up in the logs, but VS Code says there are no results. This could be a VS Code issue - I'll try to make a small repro and raise it there if it appears so.
Nope, this is totally on me. In the case where there's a space at the end of the line, the completion item returned has a range starting from the next line, which I guess is causing VS Code to filter it out.
@bwilkerson I'm having trouble reproducing this in a test (although I can reproduce it reliably through VS Code) and wonder if you have any ideas that might help understand why. Here's the behaviour I'm seeing:
open pubspec.yaml
send completion at the end of a line that contains a dependency " foo:" (with no trailing whitespace)
server returns expected results (the version numbers for package foo)
cancel the completion (don't accept any value)
modify the pubspec to add trailing space after the colon: " foo: "
send completion at the new offset (after the space)
server returns the correct completion results, but the line/col for the edit are wrong (which causes VS Code to filter them out because they're not on the correct line)
The reason the offsets of the edits are wrong seems to be that the LineInfo we get seems to be stale. The lineStarts for it are the same for both completion requests even though the file had a character inserted in the middle between those requests. Unfortunately I can't reproduce this in a test (nor can I currently attach a debugger to VS Code to debug the live instance due to another bug) so it's difficult to step through.
The LineInfo is fetched through this code here and I'm now wondering whether I should be asking a "Dart analysis driver" for non-Dart files to get their LineInfos? Perhaps that's the issue and they're not being invalidated? Although that wouldn't explain why it seems ok in the tests. If that's not correct, what's the correct way to get a LineInfo for a YAML file? (should it just be built from the content in the resourceProvider)?
I'm now wondering whether I should be asking a "Dart analysis driver" for non-Dart files to get their LineInfos? Perhaps that's the issue and they're not being invalidated?
That seems quite likely to be the case.
(should it just be built from the content in the resourceProvider)?
Yes. I'd try making that change to see whether that fixes the problem.
Is this only a problem for LSP, or does this also happen in the legacy protocol?
Is this only a problem for LSP, or does this also happen in the legacy protocol?
Just LSP, but we don't need to translate positions using LineInfos for the legacy protocol (we translate them on the VS Code side in the client).
Yes. I'd try making that change to see whether that fixes the problem.
Seems like it does! :) I'm not sure why I couldn't repro in tests, I guess something must have been different. Sounds like the old code is bad anyway, so I'll just fix this. Seems like this could have affected any non-Dart file, so not just YAML here but also files being handled by plugins.
Activity
DanTup commentedon Dec 14, 2021
Hmm, this is odd. In the attached log the completion is there:
Request
Response
I can reproduce the same though - it shows up in the logs, but VS Code says there are no results. This could be a VS Code issue - I'll try to make a small repro and raise it there if it appears so.
DanTup commentedon Dec 14, 2021
Nope, this is totally on me. In the case where there's a space at the end of the line, the completion item returned has a range starting from the next line, which I guess is causing VS Code to filter it out.
DanTup commentedon Dec 14, 2021
@bwilkerson I'm having trouble reproducing this in a test (although I can reproduce it reliably through VS Code) and wonder if you have any ideas that might help understand why. Here's the behaviour I'm seeing:
pubspec.yaml" foo:"(with no trailing whitespace)foo)" foo: "The reason the offsets of the edits are wrong seems to be that the
LineInfowe get seems to be stale. ThelineStartsfor it are the same for both completion requests even though the file had a character inserted in the middle between those requests. Unfortunately I can't reproduce this in a test (nor can I currently attach a debugger to VS Code to debug the live instance due to another bug) so it's difficult to step through.The
LineInfois fetched through this code here and I'm now wondering whether I should be asking a "Dart analysis driver" for non-Dart files to get theirLineInfos? Perhaps that's the issue and they're not being invalidated? Although that wouldn't explain why it seems ok in the tests. If that's not correct, what's the correct way to get aLineInfofor a YAML file? (should it just be built from the content in theresourceProvider)?https://github.com/dart-lang/sdk/blob/979f3ea79ee188ec2e0c039a3186ebd28e0f636c/pkg/analysis_server/lib/src/lsp/lsp_analysis_server.dart#L264-L270
bwilkerson commentedon Dec 14, 2021
That seems quite likely to be the case.
Yes. I'd try making that change to see whether that fixes the problem.
Is this only a problem for LSP, or does this also happen in the legacy protocol?
DanTup commentedon Dec 14, 2021
Just LSP, but we don't need to translate positions using
LineInfos for the legacy protocol (we translate them on the VS Code side in the client).Seems like it does! :) I'm not sure why I couldn't repro in tests, I guess something must have been different. Sounds like the old code is bad anyway, so I'll just fix this. Seems like this could have affected any non-Dart file, so not just YAML here but also files being handled by plugins.
DanTup commentedon Dec 29, 2021
Fixed by dart-lang/sdk@295aea1.