Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
prattmic opened this issue May 24, 2024 · 4 comments
Open

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

prattmic opened this issue May 24, 2024 · 4 comments
Assignees
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@prattmic
Copy link
Member

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 prattmic added gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. labels May 24, 2024
@gopherbot gopherbot added this to the Unreleased milestone May 24, 2024
@prattmic
Copy link
Member Author

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

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

@adonovan
Copy link
Member

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
Copy link
Member Author

prattmic commented May 24, 2024

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
Copy link
Contributor

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.

@findleyr findleyr modified the milestones: Unreleased, gopls/backlog May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants