x/tools/gopls: missing metadata for import

[stamblerre]

I've noticed a few times that after adding and removing log.Printfs that I get an error saying that there is no metadata for the log package. This seems like something is going wrong with our metadata invalidation logic in (*snapshot).clone.

[stamblerre]

I've been noticing this again and actually saw it specifically when I manually added imports from a quickfix.

[stamblerre]

Ok yep, this is easily reproducible by adding a symbol from an unimported package and accepting the quick fix. Will investigate.

Edit: Less easily reproducible than I thought. I reproduced it by adding os.Stat("") to golang.org/x/tools/internal/lsp/mod/code_lens.go at 5b9ef24. Note that the only other import of "os" is in the mod_test.go file, which is an in-package test.

[gopherbot]

Change https://golang.org/cl/252681 mentions this issue: internal/lsp/regtest: reproduce golang/go#40685

[stamblerre]

To clarify, while this is reproducible with a quick fix, I have also noticed it when running goimports on save, rather than with a quick fix.

[stamblerre]

Just noticed that my repro case test failed for all but Go 1.14, so this may be a Go command bug, which would explain its recent appearance.

Edit: Confirming that I cannot reproduce with Go 1.14.

[stamblerre]

Looks like this is a consequence of #36857--an overlaid file in a package that has a test variant really needs to be added both to the original package and its test variant. We currently don't handle this, but I think the ordering of the pre-1.15 go list output resulted in the file getting added to the non-test variant package.

Now it's being added to the test variant, which results in incorrect gopls diagnostics. The complete fix would be fixing #36857, but since native overlays are coming to the Go command, I'll just apply a simple "band-aid" fix.

[gopherbot]

Change https://golang.org/cl/253800 mentions this issue: internal/lsp, go/packages: fix Go 1.15-related overlay bug