Skip to content
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: forgets/complains about unchanged types/code #38924

bmhatfield opened this issue May 7, 2020 · 5 comments

x/tools/gopls: forgets/complains about unchanged types/code #38924

bmhatfield opened this issue May 7, 2020 · 5 comments


Copy link

@bmhatfield bmhatfield commented May 7, 2020

What version of Go are you using (go version)?

% go version
go version go1.14.2 darwin/amd64

Notably, I update gopls manually very regularly. I am running from a go install from current master: a1532b81. This issue affects (possibly many) previous commits as well (it was not introduced in a1532b81).

What operating system and processor architecture are you using (go env)?

go env Output

What did you do?

This reproduces frequently, but not reliably enough to come up with a process.

In general, I have a large-ish codebase. While changing code (unrelated code to what breaks), I frequently will see various other directories highlight red in VSCode.

Some things that I am not doing might be relevant here:

  • I am not changing branches/rebasing/otherwise moving files around.
  • I am not editing code that should directly affect the code that starts breaking

What did you expect to see?

I expect only actual compilation/code errors to be displayed as errors.

What did you see instead?

Looking at the errors, I see stuff like:

Screen Shot 2020-05-07 at 1 31 52 PM


Screen Shot 2020-05-07 at 12 35 41 PM

Neither error is valid. Neither error is related to changed code. The second error in particular is clearly not valid, as the error itself is tautologically inconsistent (type a cannot be used as type a).

Using VSCode's Go: Restart Language Server resolves the issue for some period of time, but it tends to come back in minutes-to-hours. One thing I noticed is there does tend to be some consistency to the code it becomes unhappy about - given the same general work, it will start complaining about the same exact (but still unrelated and unchanged) type, in the same file, at the same location.

Happy to gather more information here as appropriate.

@gopherbot gopherbot added this to the Unreleased milestone May 7, 2020
@gopherbot gopherbot added the Tools label May 7, 2020
Copy link

@gopherbot gopherbot commented May 7, 2020

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.

@gopherbot gopherbot added the gopls label May 7, 2020
Copy link

@bmhatfield bmhatfield commented May 7, 2020

I caught part of this live again.

A clue:

I have a function definition which exists in file A. That function definition returns a type which exists in a package (P) different than A's package. The import that provides that type to file A is import aliased.

The *invalid error occurs in file B, in a separate package from A - it does not import P (aliased or unaliased).

If I open the file (A) with the function definition (and the import alias), both files stop reporting errors. If I close the file with the function definition, both files start reporting errors again.

Copy link

@stamblerre stamblerre commented May 7, 2020

Thanks for the detailed report! The second issue you described should be covered by #38403, which was just resolved. Please upgrade to master and do let us know if you see this issue again.

Regarding the first issue, can you share your logs when you see this happen? Details on how to capture them here.

Copy link

@bmhatfield bmhatfield commented May 7, 2020

Thanks! I've just upgraded, and I will continue watching! What luck that this just got closed, very exciting :-)

EDIT: I did try to search for things that sounded like this, not sure how I missed that issue, apologies for the duplicate for that part.

Copy link

@bmhatfield bmhatfield commented May 13, 2020

It's been about a week, and I have not seen this issue since upgrading past the point where #38403 was fixed. Closing this for now, I will file a new issue with as much information as I can capture if it recurs.

@bmhatfield bmhatfield closed this May 13, 2020
@golang golang locked and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants