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/cmd/gopls: CL 178724 results in "no package found" parse error #32354
Comments
Is this only for this specific file, or is it the case for other files too? |
This is the only test that fails... but that doesn't preclude there being other situations. I just found this test failure on trying to upgrade to the latest tools so reported. |
Ok, thanks. Just to confirm, you're certain it's specifically that CL that caused it to break? I'm just surprised because that CL fixed an issue with dependencies, and your test code doesn't have any dependencies. |
Oh, my mistake, I see that you do. Will investigate further. |
I can reproduce this when introducing a new test file.
|
|
Having the same problem. In my situation pretty much all functionality stops working. No For hover:
For Cmd + LClick:
Since I redacted my files' names, some relevant info about them:
Also important to mention that this seems to be intermittent and comes and goes (though I usually reload the window to get rid of this) Hopefully this helps! PS : I also sometimes get these (in this case, it's the strings.ContainsAny() function), it gets underlined in red:
I confirmed that the |
Change https://golang.org/cl/181317 mentions this issue: |
Yes they are probably the same issue. I didn't mark them "fixed" in my cl because there is another bug #30100 that can cause similar behavior in tests only (the bug description doesn't really indicate it, but it can cause test files to get stuck with the "no package for file" error). |
Same issue here. I use gopls with neoclide/coc.nvim with gopls running in server mode: When I try to go to definition I have following lines in console:
|
If the context is canceled (or times out) during parsing, we were previously caching the package with no *ast.Files. Any further LSP queries against that package would fail because the package is already loaded, but none of the files are mapped to the package. Fix by propagating non-parse errors as "fatal" errors in parseFiles. typeCheck will propagate these errors and not cache the package. I also fixed the package cache to not cache errors loading packages. If you get an error like "context canceled" then none of the package's files are mapped to the package. This prevents the package from ever getting unmapped when its files are updated. I also added a retry mechanism where if the current request is not canceled but the package failed to load due to a previous request being canceled, this request can try loading the package again. Updates golang/go#32354, golang/go#32360 Change-Id: I466ddb8d336aeecf6e50f9f6d040787a86a60ca0 GitHub-Last-Rev: 5f1e7ef GitHub-Pull-Request: #110 Reviewed-on: https://go-review.googlesource.com/c/tools/+/181317 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Are people still seeing this error on master? Some fixes got merged today that should help. |
Thanks @muirrn, this was indeed addressed by one of those many CLs! |
Same, can confirm the fix. Thank you! |
Confirm here too. Thank you all :) |
Confirm the issue as well. Running the latest version of gopls. |
@LordNoteworthy: Are you seeing this issue, or confirming the fix? If you are seeing an issue, please file a new bug here. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I have a test that passes normally, but fails following https://go-review.googlesource.com/c/tools/+/178724; the error message I get back is:
The test is https://github.com/myitcv/govim/blob/latest_tools/cmd/govim/testdata/complete_watched.txt. The scope of the test is roughly:
main.go
in Vimmain.go
const.go
) that is not loaded in Vim (but watched via agovim
file watcher); thegovim
file watcher then callsdidOpen
/didChange
as requiredconst.go
const.go
Following https://go-review.googlesource.com/c/tools/+/178724, however, I now get an error back when the
govim
file watcher first tellsgopls
about the file viadidOpen
:But as you can see from the log, the file contents sent to
gopls
are valid Go.govim
logThis worked consistently prior to https://go-review.googlesource.com/c/tools/+/178724 and fails consistently after it.
What did you expect to see?
A passing test.
What did you see instead?
The parse error above, and hence a failing test (because the completion fails).
cc @stamblerre @ianthehat
The text was updated successfully, but these errors were encountered: