x/tools/gopls: respect go/analysis.Pass.RunDespiteErrors

[muirdm]

I've started to see this panic sometimes as I type:

panic: interface conversion: types.Type is nil, not *types.Struct

goroutine 9909 [running]:
golang.org/x/tools/go/analysis/passes/structtag.run.func1(0x17c1e80, 0xc01c8f8ca0)
	/Users/muir/projects/tools/go/analysis/passes/structtag/structtag.go:43 +0x15c
golang.org/x/tools/go/ast/inspector.(*Inspector).Preorder(0xc02446f500, 0xc0108facb0, 0x1, 0x1, 0xc0108faca0)
	/Users/muir/projects/tools/go/ast/inspector/inspector.go:77 +0x9f
golang.org/x/tools/go/analysis/passes/structtag.run(0xc02ca6e1e0, 0xc016181600, 0xc00002a3e0, 0xc008f81600, 0x9)
	/Users/muir/projects/tools/go/analysis/passes/structtag/structtag.go:42 +0xca
golang.org/x/tools/internal/lsp/source.(*Action).execOnce(0xc024473c80, 0x17cb480, 0xc0244708c0, 0xc00021c840, 0xc0031d46c8, 0x10)
	/Users/muir/projects/tools/internal/lsp/source/analysis.go:174 +0x80b
golang.org/x/tools/internal/lsp/source.(*Action).exec.func1()
	/Users/muir/projects/tools/internal/lsp/source/analysis.go:108 +0x4e
sync.(*Once).Do(0xc024473c80, 0xc0031d4708)
	/usr/local/go/src/sync/once.go:44 +0xb3
golang.org/x/tools/internal/lsp/source.(*Action).exec(0xc024473c80, 0x17cb480, 0xc0244708c0, 0xc00021c840, 0xc00c59edd0, 0xc0031d4790)
	/Users/muir/projects/tools/internal/lsp/source/analysis.go:107 +0x8b
golang.org/x/tools/internal/lsp/source.execAll.func1(0xc000000008, 0x170d780)
	/Users/muir/projects/tools/internal/lsp/source/analysis.go:99 +0x48
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc024ec2420, 0xc02446f240)
	/Users/muir/projects/<project>/go/pkg/mod/golang.org/x/sync@v0.0.0-20190423024810-112230192c58/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/Users/muir/projects/<project>/go/pkg/mod/golang.org/x/sync@v0.0.0-20190423024810-112230192c58/errgroup/errgroup.go:54 +0x66

[stamblerre]

Does the code that this happens in have build tags? I wouldn't be surprised if this were another instance of #32413.

[muirdm]

No build tags involved in this case, but you are probably right it is the same issue. I assume type information was incomplete because I was in the middle of typing, but we still run the analyzers (#32413 (comment)). Closing as dupe of #32413.

[stamblerre]

Well, we shouldn't run analyzers if the type information is incomplete actually - we only run analyses when we didn't return any diagnostics for the file.

[gopherbot]

Change https://golang.org/cl/190908 mentions this issue: go/analysis: handle common nil pointers

[stamblerre]

We've added a recover in the go/analysis driver to handle cases like these (see https://github.com/golang/tools/blob/b1451cf3445bfc43d9982a3e85bec2dacced42ce/internal/lsp/cache/analysis.go#L218), but the correct solution will be to actually respect the go/analysis.Pass.RunDespiteErrors field. This can only be done once we have better support for build tags.

[stamblerre]

The panics have been covered now that our analysis runner has a recover in it. I'll close this issue in favor of the build tags one, since the two are the same.