-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/gopls: changing package names returns an error #32149
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
Comments
Change https://golang.org/cl/178162 mentions this issue: |
Re-opening because this doesn't work if you don't save the file. I imagine that's likely because go/packages needs to be looking at the overlay for the package name, but I'm not certain. |
/cc @matloob |
This issue persists. It takes saving the file and then editing it for the diagnostic to go away. Logs
[Trace - 6:19:46 PM] Received notification 'window/logMessage' in 0ms.
Params: {"type":3,"message":"14.588171ms for GOROOT=$GOROOT GOPATH=$HOME/code GO111MODULE=on PWD=$HOME/mod1 go \"list\" \"-e\" \"-json\" \"-compiled=true\" \"-test=true\" \"-export=false\" \"-deps=true\" \"-find=false\" \"--\" \"builtin\", stderr: \u003c\u003c\u003e\u003e\n"}
|
When typeCheck() in check.go is given the file where the package name has been modified, it calls types.NewChecker(...).Files() to do an incremental check, but of course the type checker doesn't like seeing a new package. Don't know how to recover yet. |
I've been looking at this a bit because of #37978, so I may add some regression tests for this. The fix will probably look like https://golang.org/cl/225317, but without invalidating package IDs from workspace packages unless a package has been deleted. |
this appears to be a packages.Load error: If the overlay is in a different package from the file on disk, the wrong package is returned. |
@pjweinb: Can this issue be closed, or is there other work left for this change? I guess the last step might be to remove the |
I actually just took a look at the test, and it seems we can't enable it because the regression tests don't yet support asserting that no diagnostics (rather than empty diagnostics) come in. @findleyr: this is basically the same case as I mentioned in #36960 (comment). |
Change https://golang.org/cl/229777 mentions this issue: |
Originally reported in microsoft/vscode-go#2520
If you edit the package name, something in the caching causes persistent errors until a gopls restart.
The text was updated successfully, but these errors were encountered: