x/tools/gopls: crash in type checker with cgo

[ngld]

gopls version: v0.6.5
gopls flags:
extension version: 0.22.1
environment: Visual Studio Code darwin
initialization error: undefined
manual restart count: 0
total start count: 1

Describe what you observed.

I was editing a Go function when the crash notice showed up. I didn't notice any strange behavior or issues before the message.

panic: unreachable

goroutine 251809 [running]:
go/types.(*Checker).handleBailout(0xc006f3fd40, 0xc00e30b9f0)
	  check.go:244  0x98
panic(0x18b2120, 0x1b111f0)
	  panic.go:969  0x1b9
go/types.unreachable(...)
	  errors.go:24
go/types.(*Checker).assignment(0xc006f3fd40, 0xc00f236d40, 0x1b2a460, 0xc00e566120, 0x19f3586, 0xa)
	  assignments.go:28  0x78f
go/types.(*Checker).initVar(0xc006f3fd40, 0xc017d9f590, 0xc00f236d40, 0x19f3586, 0xa, 0xba6b800, 0x8)
	  assignments.go:124  0x148
go/types.(*Checker).initVars(0xc006f3fd40, 0xc00c001d08, 0x1, 0x1, 0xc00d056f50, 0x1, 0x1, 0x0)
	  assignments.go:247  0x599
go/types.(*Checker).shortVarDecl(0xc006f3fd40, 0x264d506, 0xc00d056f40, 0x1, 0x1, 0xc00d056f50, 0x1, 0x1)
	  assignments.go:322  0x28c
go/types.(*Checker).stmt(0xc006f3fd40, 0x0, 0x1b36060, 0xc00da00e40)
	  stmt.go:398  0x36aa
go/types.(*Checker).stmtList(0xc006f3fd40, 0x0, 0xc004068b00, 0x8, 0x8)
	  stmt.go:120  0xd1
go/types.(*Checker).funcBody(0xc006f3fd40, 0xc005b70e40, 0xc009ce4c80, 0x14, 0xc00e5675c0, 0xc00daafb60, 0x0, 0x0)
	  stmt.go:42  0x21c
go/types.(*Checker).funcDecl.func1()
	  decl.go:662  0x67
go/types.(*Checker).processDelayed(0xc006f3fd40, 0x0)
	  check.go:290  0x3e
go/types.(*Checker).checkFiles(0xc006f3fd40, 0xc00b44bea0, 0x3, 0x3, 0x0, 0x0)
	  check.go:266  0xd0
go/types.(*Checker).Files(...)
	  check.go:249
golang.org/x/tools/internal/lsp/cache.typeCheck(0x1b38ae0, 0xc00da00240, 0xc011abe380, 0xc00b586f70, 0x2, 0xc00daae1b0, 0x0, 0x0, 0x0)
	  check.go:431  0x1273
golang.org/x/tools/internal/lsp/cache.(*snapshot).buildPackageHandle.func1(0x1b38ae0, 0xc00da00240, 0x1b24ca0, 0xc011abe380, 0x0, 0x0)
	  check.go:97  0x1bc
golang.org/x/tools/internal/memoize.(*Handle).run.func1(0xc00d056a50, 0x1b38ae0, 0xc00da00240, 0xc00b44bce0, 0x1b24ca0, 0xc011abe380, 0xc0123f8420)
	  memoize.go:322  0xa8
created by golang.org/x/tools/internal/memoize.(*Handle).run
	  memoize.go:315  0x185
[Error - 10:24:39 PM] 

The full log is huge (20k lines and 1 MiB) so I'll just provide the last few messages and the function I was working on at the time (seems relevant considering the stacktrace). However, I have the full log saved so feel free to ask for specific parts.

[Error - 10:24:39 PM] 2021/02/18 22:24:39 github.com/ngld/knossos/packages/libknossos/api: no dep handle for C: no metadata for C
	snapshot=1831

[Error - 10:24:39 PM] 2021/02/18 22:24:39 github.com/ngld/knossos/packages/libknossos/api: no dep handle for C: no metadata for C
	snapshot=1832

The same message appeared several times. This issue seems to occur whenever I change the C preamble and vanishes once I click the "Regenerate cgo definitions" action.

Here's the function I was working on. I just finished typing C.GoStringN( when the crash occured.

//export KnossosHandleRequest
func KnossosHandleRequest(urlPtr *C.char, urlLen C.size_t, bodyPtr unsafe.Pointer, bodyLen C.size_t) *C.KnossosResponse {
	url := C.GoStringN()

	resp := C.make_response()
	resp.status_code = 200
	resp.header_count = 1
	resp.headers = C.make_header_array(1)

	C.set_header(resp.headers, 0, "Content-Type", "text/plain")
	C.set_body(resp, "Hello World")

	return resp
}

The installed Go version is 1.15.8.

[findleyr]

Thanks for the report. This is a dupe of #44353, which was just reported yesterday. Thanks for the extra info -- the go version and repro are very helpful.

Given that none of this executing code is new, I'm a little surprised to get two reports in such quick succession.

[findleyr]

As mentioned in the other issue: from the panic site and description, the assignment operand being checked is probably a cgofunc. Perhaps we simply need to add a case here, but I need to think about it a bit more:
https://cs.opensource.google/go/go/+/master:src/go/types/assignments.go;l=26;drc=2f0da6d9e29d9b9d5a4d10427ca9f71d12bbacc8

Note that gopls will have set (via reflection) types.Config.go115UsesCgo, which I think is necessary to hit this panic.

CC @griesemer @mdempsky

[findleyr]

FWIW, this is similar to #39634 crash 12, which is fixed at Go tip.

It will be a while before gopls gets this fix, but given the rarity of this particular panic I don't think we need to take extreme measures to avoid it.