Thanks for the report. This looks like a dupe of golang/vscode-go#3207, and it's very interesting that the package ID in question is exactly the same. Are you by any chance a colleague of @amirrmonfared? I ask because if this isn't coming from the exact same code base, it's possible that there's something about the package layout of easyjson that exacerbates this bug.

@painhardcore I should also ask: does this crash occur in an open source repository, from which we could try to reproduce?

@findleyr Yep, his my colleague and has similar issue. Not sure about open source repo that we can match(we have vendored packages and easyjson)...

1.15.0 and 1.15.1 are affected and have same panic trace, but 1.14.2 works fine

But so far I found a small trick to work

1. Close VScode
2. Downgrade to stable that works go install golang.org/x/tools/gopls@v0.14.2
3. Open VScode

VScode will update the gopls anyway, but the current gopls instance wont be effected. So if I need other brach in a new window(I use git worktree) - I just downgrade it before opening new VScode.

But so far I found a small trick to work

To be clear, downgrading is not a long-term solution. We need to fix this bug.

I believe this problem is related to the use of a tools.go pattern, as is described here:
https://marcofranssen.nl/manage-go-tools-via-go-modules

"github.com/mailru/easyjson/easyjson" is a command, not an importable package (i.e. it is package main), so the only reason to have it in an import statement would be to intentionally introduce a tool dependency. However, I have tried many different ways of importing it, and can't produce a crash.

Can you search for this import in your codebase, and share details about the file containing the import? If possible, I would love to see the full header of the file with the import (the package name and imports, as well as any //go:build comments). I'd also like to know whether the file is a _test.go file. Does the crash occur as soon as you open your repository, or only when the importing file is open?

Yep, we have a file, that we keep to have everything in vendor.

//go:build tools
// +build tools

// This file tracks toolings that aren't directly used by repo
// but they are required to build the project.
// Refer to https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module
package back

import (
	_ "github.com/mailru/easyjson/easyjson"
	_ "github.com/quasilyte/go-ruleguard/dsl" // For .github/gorules/rules.go.
)

I don't understand how its connected with _test.go files, but apparently something triggers background scan or smth:

I can go and edit .go files and everything is OK. Until I go to _test.go file and do "go to definition" it's crashing.

But if I remove that file with tools - it works OK, and crashes only when I bring it back.

BTW the new link tools is https://go.dev/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

@findleyr and I found the issue, its because the file with these tools is called tools_test.go 🤣
And apparently if we name it tools.go - everything work without panics. We need to doublecheck with @amirrmonfared just to be sure.
I don't know it's a bug but it worked before.

Thanks. For some reason I still can't reproduce, but this is enough information for me to put together a fix. Transferring to the gopls issue tracker.

Change https://go.dev/cl/569035 mentions this issue: gopls/internal/cache: prune broken edges to command-line-arguments pkgs

@findleyr reproducable repo https://github.com/painhardcore/goplscrash . Just go to tools/tools_test.go in VScode and gopls will crash.

Indeed it does! Apparently the file must be in a nested directory. Thank you for the reproducer!

Yep, in our case file tools_test.go was in root folder, so every test file in a big repo was like a trigger 😄

Change https://go.dev/cl/569437 mentions this issue: [gopls-release-branch.0.15] gopls/internal/cache: prune broken edges to command-line-arguments pkgs

@painhardcore and @amirrmonfared, huge thanks for your conscientious help resolving this bug. The CL above should fix this crash. However, we have a couple other issues to sort out before we cut gopls@v0.15.2 with this fix.

@painhardcore and @amirrmonfared, huge thanks for your conscientious help resolving this bug. The CL above should fix this crash. However, we have a couple other issues to sort out before we cut gopls@v0.15.2 with this fix.

Thanks.
I fixed the issue in our repo, so we can work on 0.15.1

Thanks a lot @findleyr for your support and thanks to @painhardcore for solving the issue in our repo ❤️

This fix is included in our prerelease:

go install golang.org/x/tools/gopls@v0.15.2-pre.1