x/tools/gopls: error reporting type as `chan<- invalid type`

[prattmic]

gopls version

Build info ---------- golang.org/x/tools/gopls v0.15.3 golang.org/x/tools/gopls@v0.15.3 h1:zbdOidFrPTc8Bx0YrN5QKgJ0zCjyGi0L27sKQ/bDG5o= github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak= github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI= golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y= golang.org/x/mod@v0.15.0 h1:SernR4v+D55NyBH2QiEQrlBAnj1ECL6AGrA5+dPaMY8= golang.org/x/sync@v0.6.0 h1:5BMeUDZ7vkXGfEr1x9B4bRcTH4lpkTkpdh0T/J+qjbQ= golang.org/x/telemetry@v0.0.0-20240209200032-7b892fcb8a78 h1:vcVnuftN4J4UKLRcgetjzfU9FjjgXUUYUc3JhFplgV4= golang.org/x/text@v0.14.0 h1:ScX5w1eTa3QqT8oi6+ziP7dTV1S2+ALU0bI+0zXKWiQ= golang.org/x/tools@v0.18.1-0.20240412183611-d92ae0781217 h1:uH9jJYgeLCvblH0S+03kFO0qUDxRkbLRLFiKVVDl7ak= golang.org/x/vuln@v1.0.1 h1:KUas02EjQK5LTuIx1OylBQdKKZ9jeugs+HiqO5HormU= honnef.co/go/tools@v0.4.6 h1:oFEHCKeID7to/3autwsWfnuv69j3NsfcXbvJKuIcep8= mvdan.cc/gofumpt@v0.6.0 h1:G3QvahNDmpD+Aek/bNOLrFR2XC6ZAdo62dZu65gmwGo= mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8= go: go1.23-20240419-RC02 cl/626470163 +7f76c00fc5 X:fieldtrack,boringcrypto

go env

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/usr/local/google/home/mpratt/.cache/go-build'
GOENV='/usr/local/google/home/mpratt/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/usr/local/google/home/mpratt/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/usr/local/google/home/mpratt/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/google/home/mpratt/src/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/google/home/mpratt/src/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.23-3ea2be1e47 Fri May 24 13:54:20 2024 +0000'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/usr/local/google/home/mpratt/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/usr/local/google/home/mpratt/src/go/src/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1993295912=/tmp/go-build -gno-record-gcc-switches'

What did you do?

Added this test in std [1] to os/exec_test.go:

// Copyright 2024 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

package os_test

import (
        "os"
        "os/signal"
        "runtime"
        "testing"
        "time"
)

func TestProcessLiteral(t *testing.T) {
        if runtime.GOOS == "windows" {
                t.Skip("Process literals do not work on Windows. FindProcess/etc must initialize the process handle")
        }

        c := make(chan os.Signal, 1)
        signal.Notify(c, os.Interrupt)
        defer signal.Stop(c)

        p := &os.Process{Pid: os.Getpid()}
        if err := p.Signal(os.Interrupt); err != nil {
                t.Fatalf("Signal got err %v want nil", err)
        }

        // Verify we actually received the signal.
        select {
        case <-time.After(1*time.Second):
                t.Errorf("timeout waiting for signal")
        case <-c:
                // Good
        }
}

[1] My Go tree is checked out at 3ea2be1. The go binary in gopls' PATH is the toolchain built from the same checkout.

What did you see happen?

My editor (nvim, using the built-in LSP client) reported an error on the signal.Notify line: cannot use c (variable of type chan os.Signal) as chan<- invalid type value in argument to signal.Notify, despite the fact that this test compiles successfully.

(I may have had a type error on this line when I was originally writing it, I can't quite recall)

What did you expect to see?

No error

Editor and settings

nvim 0.10 using the built in LSP client. gopls is configured using https://github.com/neovim/nvim-lspconfig require("lspconfig").gopls.setup{} (no special gopls settings).

I work in the Go tree, but typically don't have my dev Go toolchain in PATH for stability reasons. I invoke my editor with PATH=/path/to/dev/go:$PATH nvim os/exec_test.go so gopls will pick up the dev toolchain. GOROOT is not explicitly set in the environment. This setup seems to be generally working correctly, xrefs in std and cmd work.

Logs

Here are the logs from earlier. I will see if I can reproduce with a higher log level.

[START][2024-05-24 11:14:35] LSP logging initiated
[ERROR][2024-05-24 11:14:35] ...lsp/handlers.lua:623    "2024/05/24 11:14:35 warning: while diagnosing orphaned files: session is shut down\n"
[START][2024-05-24 11:14:47] LSP logging initiated
[ERROR][2024-05-24 11:14:47] ...lsp/handlers.lua:623    '2024/05/24 11:14:47 unable to compute deps errors: stat : no such file or directory\n\tpackage="_/tmp/TestScripts856984105/001/git/modlegacy1-old/p1"\n'
[ERROR][2024-05-24 11:15:37] ...lsp/handlers.lua:623    "2024/05/24 11:15:37 warning: while diagnosing orphaned files: session is shut down\n"
[START][2024-05-24 11:16:05] LSP logging initiated
[ERROR][2024-05-24 11:16:05] ...lsp/handlers.lua:623    '2024/05/24 11:16:05 unable to compute deps errors: stat : no such file or directory\n\tpackage="_/tmp/TestScripts856984105/001/git/modlegacy1-old/p1"\n'
[ERROR][2024-05-24 11:16:10] ...lsp/handlers.lua:623    "2024/05/24 11:16:10 warning: while diagnosing orphaned files: session is shut down\n"
[START][2024-05-24 11:59:36] LSP logging initiated
[ERROR][2024-05-24 11:59:36] ...lsp/handlers.lua:623    "2024/05/24 11:59:36 go/packages.Load #1: /usr/bin/gopackagesdriver: exit status 1: gopkgsdriver: stdlib.Packages: reading stdlib .a files: reading zip of .a files: open <REDACTED, internal monorepo path>
[ERROR][2024-05-24 11:59:36] ...lsp/handlers.lua:623    "2024/05/24 11:59:36 initial workspace load failed: packages.Load error: /usr/bin/gopackagesdriver: exit status 1: gopkgsdriver: stdlib.Packages: reading stdlib .a files: reading zip of .a files: <REDACTED, internal monorepo path>
[ERROR][2024-05-24 11:59:36] ...lsp/handlers.lua:623    "2024/05/24 11:59:36 go/packages.Load #2: /usr/bin/gopackagesdriver: exit status 1: gopkgsdriver: stdlib.Packages: reading stdlib .a files: reading zip of .a files: <REDACTED, internal monorepo path>
[ERROR][2024-05-24 11:59:36] ...lsp/handlers.lua:623    "2024/05/24 11:59:36 MetadataForFile: packages.Load error: /usr/bin/gopackagesdriver: exit status 1: gopkgsdriver: stdlib.Packages: reading stdlib .a files: reading zip of .a files: <REDACTED, internal monorepo path>
[ERROR][2024-05-24 11:59:37] ...lsp/handlers.lua:623    "2024/05/24 11:59:37 errors loading workspace: packages.Load error: /usr/bin/gopackagesdriver: exit status 1: gopkgsdriver: stdlib.Packages: reading stdlib .a files: reading zip of .a files: <REDACTED, internal monorepo path>

The gopkgsdriver errors should be unrelated from a completely different instance of my editor outside of my Go checkout. But perhaps there is some confusion going on here?

[prattmic]

I will see if I can reproduce with a higher log level.

Unfortunately this issue does not reproduce when I restart my editor. :(

[adonovan]

I can't reproduce it in Emacs+eglot either. Did you transiently break the definition of os.Signal (e.g. delete or rename it)? This might explain why the type checker sees a chan invalid type. Of course fixing the breakage should have suppressed the diagnostic, but there could be consistency problem, i.e. a missing change notification. (We saw a variant of that class of problems just this morning with Emacs+eglot.)

[prattmic]

I did not directly break the definition of Signal, but I have been editing Process (also in os/exec.go), so I may have transiently introduced an error that broke the whole file?

(I think I wrote the whole test before editing exec.go, but I honestly can't remember with certainty.)

[findleyr]

So, my first thought here was a missed didChangeWatchedFiles notification, but if you are on neovim v0.9+, file watching should be supported.

A second thought could be that this is related to the use of the internal gopackagesdriver. You may want to try setting GOPACKAGESDRIVER=off in your environment.

It will be hard to investigate this without a reproducer.