New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: invalidate file "unloadability" when name/imports change #40312
Comments
Interesting that this is not an issue on OSX but on Windows/WSL. @stamblerre @heshik @mjyeaney Is it possible to get the memory and cpu profiles of
And then, run @heshik - if you have more specific instructions for capturing profiles, please let us know. |
@mjyeaney Thanks! Unfortunately, the cpu profile is empty - looks like gopls isn't doing any work. If you are seeing autocomplete doesn't respond, maybe we should get the trace instead. Do you see the trace in the output channel ( |
There's lots of trace output, but after uninstalling last night and re-installing, autocomplete hasn't stalled yet (just LOTS of memory use for a very small code base). I'll keep coding with this on and wait for it to stall (doesn't seem to take long with lots of editing). Do you want to entire trace window here? |
The full trace would be most helpful, yes. |
9 total files (!!), only a single |
Ok, so that indicates that there's a bug here. Please share the |
Will do - few meetings, should be able to this evening (EDT). Standby. |
While I'm getting back to things, I've noticed when autosuggest fails there is line after line of these types of messages in the output window:
The only way I found to get thigs working is to kill the
Was able to switch to the console during a laptop fan ramp-up, caught this message:
During this time (at least 5 seconds), the process list showed > 90% CPU...note that the rest of the background refreshes are ~150 - 200 msec. |
It really does sound like there's a bug here, but we will need a complete log to understand what's going on. Even if you don't notice unusual activity as you're working, it will still be helpful to see a log. |
Here's what I have so far - this is from the VS Code output window for
|
Can you please increase the verbosity of the logging? https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#vs-code has the information on how to do this. |
Done - lots here, but almost immediately I lost intellisense / autocomplete (see repeated
|
Team - any updates here? |
Sorry for the delay. I think the issue is likely that some of your files aren't getting correctly mapped to their packages:
I wonder why |
Good catch - yes, all the In addition, once the build tags are removed these files no longer reload multiple times. The build tags are all of the following format: |
There does seem to be an additional issue here, which is that build tagged files usually get marked as "unloadable" when we cannot find their package, but if you are editing a build tagged file, we will probably keep trying to load it. We should make sure that |
I'm also getting which is preventing all symbols from being loaded from a go file (over SSH remote). This seems to happen on and off as I open go files and can happen to any of them. If symbols don't load for a particular file, they may load later after I open and close a bunch of other files. The best seems to be restart vscode or gopls and then trying to open the file that I want. Also, 1st file opened in vscode seems to always load the symbols just fine, but 2nd file opened always fails (doesn't matter which actual files). |
@igordcard: Please take a look at the |
I believe that #31668 would likely be a good way of guiding the user to solve the problem. |
Change https://golang.org/cl/271477 mentions this issue: |
Change https://golang.org/cl/276976 mentions this issue: |
Change https://golang.org/cl/277118 mentions this issue: |
Change https://golang.org/cl/298489 mentions this issue: |
See previous report in golang/vscode-go#325 ; Issue is no better on Windows / WSL (see screenshot below). Switching to OSX to continue dev work (rest of team has no issues). Note that memory will NOT climb above this, and at this point autocomplete is non-functioning and will spin CPU with a VS Code message of
Loading...
The text was updated successfully, but these errors were encountered: