x/tools/gopls: import organization sporadically failing #38669
Comments
gopherbot
added
the
Tools
|
Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here. |
|
Based on the logs, I don't think the issue is import organization, and I suspect that other features may not be working for you as well. It looks like |
|
No, not a newly created file. Here's the output of Just now I noticed this in the gopls log, maybe related? |
|
Does restarting The fix for the issue you mentioned has been merged (https://golang.org/cl/229985). Can you try rebuilding, if you're using master? |
|
Restarting doesn't help. Thanks, I will try rebuilding. |
|
No change after upgrading. Some more details:
|
|
The issue seems to be related to the failure to load the package for The $ go get golang.org/x/tools/go/packages/gopackages
$ cd /Users/alex/Projects/Sanity/gradient/pkg/system/groupcache
$ gopackages -test -json file=groupcache.go |
stamblerre
changed the title
|
Sorry, the repo isn't public. I can see if I can reproduce it with a public repo later. |
|
No worries. Looks like the "gopls": {
"verboseOutput": true,
} |
|
New log: gopls.log.gz
|
|
VS Code will not recognize the setting, but it will still work (see these docs). The Just to confirm since I haven't asked this yet - does the |
|
This is about packages in my repo in the same module, not external modules.
Thanks, I will turn it on. |
That link gives me "Permission denied". |
|
Thanks for clarifying - I'll take another look at your log and see if I can spot the issue. Regarding the verbose output setting, I'd actually suggest leaving it off in your case. It's only useful for debugging and since you have a lot of packages in your workspace it may slow things down. Sorry about the link, this one will be better: https://github.com/golang/tools/blob/master/gopls/doc/vscode.md. |
|
Change https://golang.org/cl/229988 mentions this issue: |
stamblerre
added
the
NeedsInvestigation
|
Just uploaded https://golang.org/cl/229988 which may help isolate the issue. You can rebuild $ git clone https://go.googlesource.com/tools
$ cd tools
$ git fetch "https://go.googlesource.com/tools" refs/changes/88/229988/1 && git cherry-pick FETCH_HEAD
$ cd gopls
$ go installIf you could share another log with |
stamblerre
added
WaitingForInfo
|
Thanks. Here's the log: gopls.log.gz I'm suddenly not able to reproduce the autocomplete problem for that particular package anymore; autocompletion finds its symbols, though it's only adding the import if I follow the autocompletion. On-save "organize imports" still fails to add it. Here's something potentially interesting, though:
Here, I reloaded the VSCode window and starting typed Note that autocompletions appear to be in random order even after gopls has apparently found all modules. That seems wrong to me. Also, they shouldn't disappear! But beyond that, obviously the first |
|
Another log for another package called |
|
Thank you for the new logs. Looks like there are no errors - just empty results from import organization. It's very strange that unimported completions would work and imports wouldn't. I'll let @heschik take over the investigation from here, but one thing to try is to see if Also, the issues you're seeing with completion are being tracked in #38104. |
|
I will find a public repo now and try it out. Meanwhile: |
stamblerre
removed
the
WaitingForInfo
|
Just realized my environment has None of the files I've mentioned use build tags, but I see that if I run the above command with that environment variable set, it does not organize imports: |
|
...Yup. I can reproduce it consistently in a small repo with just two files. |
|
Ah ok, glad you were able to figure this out! So this is really working as intended - We intend to improve it in future, but for now the best way to work with build tagged files is by setting |
|
I'm not sure I agree with "working as intended". These files don't contain any tags! I may be misunderstanding how Go works here, but Secondly, I understand, and I was aware, that gopls doesn't have a good solution for working with sets of _conflicting build tags. For example, if I have two files For example, we have the tag Lastly, I think you ought to emit an prominent error that shows up in VSCode informing the user that gopls is completely disabled for files containing build tags. Otherwise people are going to (continue to) waste time chasing nebulous bugs caused by the absence of support. |
|
Sorry, I should've been more clear in my response. You are correct in your understanding and right to say that this should work. I tested setting My intention was really to convey that we are aware that |
|
Thanks for the repro. Somehow |
|
Got it. Fix as soon as I write the test. |
|
Change https://golang.org/cl/230560 mentions this issue: |
|
Thanks, but closing is maybe premature? My repro repo still fails, and so does gopls when I run it with VSCode. |
|
I tested the fix with your repro, so that's pretty surprising. Are you sure you have master? (Maybe |
|
I keep forgetting there's a module cache now. By the way, I tried without the Interestingly, |
|
Yeah, it's strange but not gopls: Feel free to file a cmd/go bug for that, though I feel like I've seen it somewhere. |
What did you do?
Added a reference to a package in my project and hit "save" in VSCode.
What did you expect to see?
Import should be added automatically.
What did you see instead?
Nothing happened.
More information
This is a regression that appears to have been introduced in 0.4.0. I have no idea how to reproduce it, though it seems to happen > 50% of the time now. Project is building fine when this occurs.
Log looks normal (I am inserting a
utils.Spew()function here): gopls.log.gz.Also tested latest
master.Build info
Go info
The text was updated successfully, but these errors were encountered: