x/tools/cmd/gopls: fails on certain projects #31712
Comments
|
Can you try reloading the VSCode window after you create the module? |
|
Also, how was it working before? Is the directory in your |
stamblerre
changed the title
|
You will also need to configure this VSCode setting if you don't already have it: "go.toolsEnvVars": {
"GO111MODULE": "on"
} |
Interestingly, though, |
|
If the directory is not in your Additionally, you will require the |
|
Well, my repro instructions no longer reproduce the problem, which is encouraging! However, I still have several projects where
That was my mistake in the comment; the configuration is correct. |
|
Ok, for one of the packages that is not working for you, do you mind attaching the log output for |
|
I've been seeing similar issues to @bitfield where in some projects (or files?) the VS Code IDE seems to be fine and others not. I've not found any consistent ways to cause the issue. I even removed the I cleared the Debug Console output for There aren't any other errors. |
|
@wiredprairie: Are you on Windows? There seem to be some issues with formatting there (see #31150, which I'm currently investigating). Can you try another feature, like completion? |
|
@stamblerre - yes, Windows 10 (1809). Code completion seems to work consistently. Auto import does not. Are there other features you'd like me to try? I just looked at the linked issue; the formatting may be more than just a LF issue -- I've had it work and not work, with the same projects on Windows (and only edited on Windows). |
|
Thanks for letting me know. I will continue investigating formatting. For imports, do you have this setting configured? "[go]": {
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.organizeImports": true
},
}, |
|
I verified the settings exist (and restarted VS Code). No change. |
|
Hm, @wiredprairie, it looks like you are definitely running into #31150, which is strange because formatting should work perfectly fine on Windows (I checked yesterday). Would you be able to share your logs? (They can be found by going to "View: Debug Console" -> "Output" -> "Tasks" and selection "gopls" from the dropdown.) |
|
Sure @stamblerre
|
Here we go: |
|
Do you happen to have any build constraints in your package? Can I see the output of The errors you are seeing basically indicate that |
When you say:
Which file specifically? The only diagnostics I see in the Output tab are the same as earlier: It certainly builds, and tests pass! |
|
I looks like you are trying to do something with |
|
Two points about that:
|
|
(By the way, I can't re-open the issue, but I'd appreciate it if you would.) |
|
Is there any progress on this? I watched someone install VS Code and the Go extension from scratch the other day, and there was no auto-formatting, no auto-completion, no hover docs, and no auto-imports for them either. It's not much fun having to keep explaining that the good people at Google are working on it, but it's still early days! On the other point, should I open an issue requesting |
|
Build tags is not a decision so much as a fundamental limitation. Almost all of the features that gopls offers require type checking, which requires a valid set of build tags. |
|
Thanks for your persistence! I'm having some trouble reliably reproducing this at the moment; I noticed yesterday that when I was working on a project, |
|
The Output window will have a dropdown titled "Tasks" - |
|
I don't think that gcc would be related, but @bitfiled, what version of |
|
I'm not sure, how can I find out? |
|
You can update by running |
|
Updated... and the new version has a |
|
Ok, great thank you. I will try to add some additional logging for the "no file information" error case, and if you encounter these errors again, please update this issue with additional logs. |
|
Update to earlier. The problem has returned so the other two things (as you probably already suspected) were likely not the culprits. One thing that is consistent between the two times it happened is is that I was working in VSCode then closed my laptop's lid which is set to put it to sleep. It then hibernates after a while. When I reopen the laptop the language server isn't working (I haven't yet had the foresight to look at the output for gopls) so I restart VSCode. After it restarts I get the issue. Is there some form of cache that could be getting corrupted? |
|
gopls has no persistence of any kind, if you restart it it starts from scratch every time. It stores nothing on disk and in it's default mode aquires no os resources that could collide with a separate gopls process (like sockets). |
|
This line masks an error: func (f *goFile) GetToken(ctx context.Context) *token.File {
f.view.mu.Lock()
defer f.view.mu.Unlock()
if f.token == nil || len(f.view.contentChanges) > 0 {
if _, err := f.view.parse(ctx, f); err != nil {
return nil
}
}
return f.token
}If I throw a panic in there I get the following: func (f *goFile) GetToken(ctx context.Context) *token.File {
f.view.mu.Lock()
defer f.view.mu.Unlock()
if f.token == nil || len(f.view.contentChanges) > 0 {
if _, err := f.view.parse(ctx, f); err != nil {
panic(err)
return nil
}
}
return f.token
}I suspect this is expected behavior masked behind a I'm going to dig further for my own interest, but this says to me there's something wrong enough with the package that it just can't do anything right now. Would it be possible / advisable to run other things like formatting, imports, etc. even without the specifics that it can't run? This specific file (afaik) has no such errors. It seems like if there's a package level problem it just can't do anything. |
|
If this is a bug I'd like to tackle it if you think the scope is small enough for a first contribution. I can work on it over the next few days. If it is bigger than you'd like to give to a first time contributor since, given the interfaces, I could see how it'd be difficult to cleanly handle this error, I'm happy to defer to someone with more experience in this code-base :) |
|
Sorry for the barrage of comments. Updated my "panic" to report the specific package errors: func (f *goFile) GetToken(ctx context.Context) *token.File {
f.view.mu.Lock()
defer f.view.mu.Unlock()
if f.token == nil || len(f.view.contentChanges) > 0 {
if pkgErrs, err := f.view.parse(ctx, f); err != nil {
errString := ""
for _, e := range pkgErrs {
errString += fmt.Sprintf("%v\n", e.Error())
}
panic(errString)
return nil
}
}
return f.token
}With that I got the following This is correct, and expected. It was me being silly and having a legitimate package-level issue (missing Having said that, there is so much rich information that (IMO) should be bubbled up here. That's exactly the type of issue I would hope gopls would be reporting to me in this case. Update (to clarify): There's no error reported on the file that's actually causing this issue. I definitely see why it would be okay to not "bubble" the issue up when it comes to that file; however, the file in question is completely grey'd out with no error:
|
|
Thank you for the detailed report! Totally agree that we need to do a better job of propagating those errors. The issue here is in the way that we compute diagnostics to show the user. We basically try to match a file to its package, and then we send diagnostics for all of the errors in that package. Since you were missing a Was the file in question opened in your editor? If yes, I would've expected it to reach this code on internal/lsp/source/diagnostics.go:64: pkg := gof.GetPackage(ctx)
if pkg == nil {
return singleDiagnostic(uri, "%s is not part of a package", uri), nil
}This would then show a diagnostic to the user. If it was not open, I'm afraid there's not much we could do. If you haven't opened a file, we are not aware of it or its contents yet, and if you think it is in package, but it's actually not, it ends up orphaned. The best we could do is perhaps preemptively check all of the files in the package's directory. |
|
The file in question is the one currently inside the editor. It hits the same error. It seems that error is somehow short circuiting other tests/logic. I’ll dig into why and follow up! |
|
There are a few issues going on here:
Solution possibilitiesFirst the diagnostic function needs to be fixed to not ignore the files that are being encountered in package errors. After that there are a few paths forward:
1 may be difficult to make robust; however, 2 is easier than 1 if and only if it's possible to report a package level diagnostic. 3 is ideal but that requires understanding of why it doesn't return a pos for this error in the first place. I'm going to play with solutions for my own interest. If I land on one that works I'll submit the PR if only to elicit some discussion. |
If a package has an error that makes it completely unparsable, such as containing a .go file with no "package" statement, the error was previously unreported. Such errors would manifest as other errors. Fixes golang/go#31712
|
Change https://golang.org/cl/177605 mentions this issue: |
If a package has an error that makes it completely unparsable, such as containing a .go file with no "package" statement, the error was previously unreported. Such errors would manifest as other errors. Fixes golang/go#31712
If a package has an error that makes it completely unparsable, such as containing a .go file with no "package" statement, the error was previously unreported. Such errors would manifest as other errors. Fixes golang/go#31712
|
Pardon me, but this doesn't necessarily fix the issue. (It may fix some issues.) |
|
It does not crash now, but the problem does not seem to be solved. I still have errors like this: |
|
Do you mind filing new issues with your individual errors? This issue has been quite long and has had multiple problems reported in it, so it's difficult to follow. Let's start individual new issues for each specific error seen. |
|
@bitfield I was following this thread like watching a thriller on TV until I found it closed and your comment that
If you opened a separate issue as suggested, could you please post it here so poor souls like me with your same problem can follow? :-) And thanks for opening the ticket! |
|
@marco-m: The follow-up to this was in #32142, which was ultimately closed as working as intended. If you are experiencing a problem with |
|
@marco-m the TL;DR of that issue was 'without a go.mod file, gopls can do nothing'. |
|
We are, however, working on changing this, as tracked in #32587. |
goplssettings as here: https://github.com/golang/go/wiki/goplsSteps to reproduce:
main.gofile in a new directory.An automatic
import "os"is added. I can hover the mouse overos.Exitand see pop-up information about the function. If I delete theExit(1), place the cursor afteros.and hit Ctrl-Space, I see an auto-complete menu showing the available functions inos.Add a
go.modfile withgo mod init tmp.Delete the
import "os"line and save the file again. Now the auto import is no longer added, the hover doc does not appear, and there is no auto-complete menu.(Transferred from microsoft/vscode-go#2476)
The text was updated successfully, but these errors were encountered: