x/tools/imports: panic in (*moduleResolver).scan

[pwaller]

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

$ go version
1.12rc1

Does this issue reproduce with the latest release?

I'm on x/tools commit 44bcb96. I tried reproducing on the master branch but that crashes for a different reason. I figure this stack trace will be useful anyway.

What did you do?

Using gopls with forward (note: this workflow is out of date but the new workflow doesn't work for me for unrelated reasons) under vscode.

1. Clone https://github.com/mvdan/unparam
2. Start typing defer foobar.Baz. at the top of main.

What did you expect to see?

Nothing, because foobar.Baz. isn't valid (I made it up).

What did you see instead?

gopls reliably crashes every time.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x80cc9e]

goroutine 35 [running]:
golang.org/x/tools/imports.(*moduleResolver).scan(0xc00cf51800, 0xc00d02bd10, 0xc00cf51800, 0xc0046111d8, 0x60d709, 0x950a60, 0xb)
	/home/pwaller/.local/src/golang.org/x/tools/imports/mod.go:205 +0x17e
golang.org/x/tools/imports.addExternalCandidates(0xc00480c360, 0xc00d02bd10, 0xc0068a0580, 0x31, 0x0, 0x0)
	/home/pwaller/.local/src/golang.org/x/tools/imports/fix.go:683 +0x9b
golang.org/x/tools/imports.fixImportsDefault(0xc00d0216c0, 0xc00d009780, 0xc0068a0580, 0x31, 0xc00d009700, 0x200, 0xc004611550)
	/home/pwaller/.local/src/golang.org/x/tools/imports/fix.go:504 +0x50c
golang.org/x/tools/imports.process(0xc0068a0580, 0x31, 0xc00063b600, 0x1e9, 0x200, 0xc004611550, 0xc00d009700, 0x4645fb, 0xc0001e6000, 0xc0001c38c0, ...)
	/home/pwaller/.local/src/golang.org/x/tools/imports/imports.go:72 +0xaa0
golang.org/x/tools/imports.Process(...)
	/home/pwaller/.local/src/golang.org/x/tools/imports/imports.go:50
golang.org/x/tools/internal/lsp/source.Imports(0xa7c4e0, 0xc0039285c0, 0xc00cd93a40, 0xc00063b600, 0x1e9, 0x200, 0xba9161, 0xba934a, 0x0, 0xc001b1e180, ...)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/source/format.go:74 +0x212
golang.org/x/tools/internal/lsp.organizeImports(0xa7c4e0, 0xc0039285c0, 0xa7b8a0, 0xc0001c38c0, 0xc004d59800, 0x38, 0xc0001813b0, 0xc000181398, 0xc003f83880, 0x57018b, ...)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/imports.go:35 +0x2d1
golang.org/x/tools/internal/lsp.(*server).CodeAction(0xc00012e500, 0xa7c4e0, 0xc0039285c0, 0xc005c78900, 0xc005c78900, 0x0, 0x0, 0x1, 0x7f0503808d98)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/server.go:340 +0xd5
golang.org/x/tools/internal/lsp/protocol.serverHandler.func1(0xa7c4e0, 0xc0039285c0, 0xc0001bde30, 0xc003fce520)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/protocol/server.go:283 +0x3380
golang.org/x/tools/internal/jsonrpc2.(*Conn).run(0xc0001bde30, 0xa7c520, 0xc0000b4010, 0x0, 0x0)
	/home/pwaller/.local/src/golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:327 +0x7e5
golang.org/x/tools/internal/jsonrpc2.NewConn.func4(0xc0001bde30, 0xa7c520, 0xc0000b4010)
	/home/pwaller/.local/src/golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:107 +0x51
created by golang.org/x/tools/internal/jsonrpc2.NewConn
	/home/pwaller/.local/src/golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:106 +0x261

/cc @stamblerre

[bradfitz]

/cc @heschik @ianthehat

[heschi]

@stamblerre: I think this means that the imports code is running with GO111MODULE=on, but not in the directory that contains the go.mod file. It shouldn't panic in this case, but shouldn't gopls be running in the module directory? Or is @pwaller doing something wrong with the TCP forwarding thing?

[stamblerre]

@pwaller: do you remember what directory you opened VSCode with? I'm having trouble reproducing this exact case, though the malformed defer statement does seem to cause the goimports logic to fail (though I only see an error message, not a panic).

[pwaller]

Indeed, I cannot reproduce if I run everything in the same directory. If I run gopls from, for example, my home directory, then the crash is reproducible.

I'm opening vscode with code . from the unparam checkout.

I wasn't expecting gopls to be sensitive to where it was invoked. Is it meant to be?

[stamblerre]

VSCode sets a "rootURI" value which we then use as the "Dir" in the packages.Config - the context for this is https://golang.org/cl/153863.

[stamblerre]

Also, I was able to reproduce your issue at the commit you mentioned, but at tip, this situation causes a different nil pointer in diagnostics. I think ultimately the underlying issue is deciding what to do when the rootURI sent by VSCode is not valid for the file in question. /cc @ianthehat

[stamblerre]

Duplicate of #29174