x/tools/gopls: duplicate "undeclared name" errors following CL222237 #38136

myitcv · 2020-03-28T20:33:57Z

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

$ go version
go version devel +2e918c3aab Tue Mar 17 06:38:32 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200328031815-3db5fc6bac03
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20200328031815-3db5fc6bac03

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (`go env`)?

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build432849091=/tmp/go-build -gno-record-gcc-switches"

What did you do?

As pointed out by @findleyr in govim/govim#832 (comment), we are seeing duplicate "undeclared name" errors from gopls, as highlighted by the following govim test.

# Test for duplicate undefined errors

# Ensure we have two warnings
vim ex 'e main.go'
vimexprwait warnings.golden GOVIMTest_getqflist()

# Now create a single error and verify we see only that
vim ex 'e other.go'
vim call append '[6,"asd"]'
vimexprwait errors.golden GOVIMTest_getqflist()

-- go.mod --
module mod.com

go 1.12
-- main.go --
package main

import "fmt"

func main() {
	fmt.Printf("%v")
}
-- other.go --
package main

import "fmt"

func foo() {
	fmt.Printf("%v")
}
-- warnings.golden --
[
  {
    "bufname": "main.go",
    "col": 2,
    "lnum": 6,
    "module": "",
    "nr": 0,
    "pattern": "",
    "text": "Printf format %v reads arg #1, but call has 0 args",
    "type": "",
    "valid": 1,
    "vcol": 0
  },
  {
    "bufname": "other.go",
    "col": 2,
    "lnum": 6,
    "module": "",
    "nr": 0,
    "pattern": "",
    "text": "Printf format %v reads arg #1, but call has 0 args",
    "type": "",
    "valid": 1,
    "vcol": 0
  }
]
-- errors.golden --
[
  {
    "bufname": "other.go",
    "col": 1,
    "lnum": 7,
    "module": "",
    "nr": 0,
    "pattern": "",
    "text": "undeclared name: asd",
    "type": "",
    "valid": 1,
    "vcol": 0
  }
]

The output from the test is:

        # Test for duplicate undefined errors (0.497s)
        > vim ex 'e main.go'
        > vimexprwait warnings.golden GOVIMTest_getqflist()
        # open other.go and add a broken statement to get an error that masks the warnings (4.956s)
        > vim ex 'e other.go'
        > vim call append '[6,"asd"]'
        [stdout]
        0
        > vimexprwait errors.golden GOVIMTest_getqflist()
        [stderr]
         [
           {
             "bufname": "other.go",
             "col": 1,
             "lnum": 7,
             "module": "",
             "nr": 0,
             "pattern": "",
             "text": "undeclared name: asd",
             "type": "",
             "valid": 1,
             "vcol": 0
        -  },
        -  {
        -    "bufname": "other.go",
        -    "col": 1,
        -    "lnum": 7,
        -    "module": "",
        -    "nr": 0,
        -    "pattern": "",
        -    "text": "undeclared name: asd",
        -    "type": "",
        -    "valid": 1,
        -    "vcol": 0
           }
         ]
        [exit status 1]
        FAIL: testdata/scenario_default/test.txt:9: unexpected command failure

What did you expect to see?

The test passing

What did you see instead?

The test failed, as above.

cc @stamblerre @ridersofrohan

FYI @leitzler

The text was updated successfully, but these errors were encountered:

ridersofrohan · 2020-03-30T15:01:35Z

I can't seem to reproduce this using VSCode or running gopls tests. They only seem to return a single undeclared diagnostic. Are you able to see what the source of the diagnostic is (ex. "compiler", "undeclaredname",...)?

myitcv · 2020-03-30T15:18:17Z

Apologies, I forgot to attach the gopls log. Here it is: gopls.log

gopherbot · 2020-03-30T16:07:43Z

Change https://golang.org/cl/226417 mentions this issue: internal/lsp/regtest: create test for issue 38136

ridersofrohan · 2020-03-30T16:21:32Z

@myitcv I created a test in https://golang.org/cl/226417 using Rob's regtest framework that does the same behavior as the vim test in question. It does not seem to be returning 2 diagnostics. From the gopls log you sent, it looks like the ranges are different. The way the new type error analyzers work is that there is a check to replace existing type errors with the analyzer error if they have the same range and message.

[Trace - 16:16:07.059 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {
  "uri":"file:///tmp/artefacts/govim/cmd/govim/scenario_default/script-signs_unload_load_buffer/other.go",
  "version":2,
  "diagnostics":[
    {
      "range":{"start":{"line":6,"character":0},"end":{"line":6,"character":3}},
      "severity":1,"source":"compiler","message":"undeclared name: asd"
    },
    {
       "range":{"start":{"line":6,"character":0},"end":{"line":7,"character":0}},
       "severity":2,"source":"undeclaredname","message":"undeclared name: asd"
    }
  ],
}

@stamblerre is this a gopls thing?

myitcv · 2020-03-30T16:26:30Z

@ridersofrohan - are the configurations identical, comparing your test with the govim test?

stamblerre · 2020-03-30T17:27:02Z

@ridersofrohan: It looks like the ranges aren't the same for these errors - is that causing the problem, maybe?

gopherbot · 2020-04-02T15:37:45Z

Change https://golang.org/cl/226777 mentions this issue: internal/lsp: add type error fixes to existing diagnostics

myitcv · 2020-04-02T17:01:08Z

What's the status here @stamblerre - did you close this by accident?

stamblerre · 2020-04-02T17:01:50Z

Nope - the above CL fixes the test.

myitcv · 2020-04-02T17:08:17Z

Ah sorry, I hadn't appreciated that. I saw:

Updates golang/go#38136

and assumed there were further CLs to follow.

leitzler · 2020-04-02T17:11:24Z

Isn’t it easier to track progress if issues are closed after the CL is merged?

stamblerre · 2020-04-02T17:13:43Z

Ah, sorry I see what you meant now - I have a couple of analysis-related CLs in flight right now, and I forgot which one I had merged.

myitcv · 2020-04-02T17:23:10Z

I see that https://go-review.googlesource.com/c/tools/+/226962 has actually fixed this. https://go-review.googlesource.com/c/tools/+/226777/ is not merged.

stamblerre · 2020-04-03T15:46:39Z

Ah, ok since this is fixed I will close the issue. We'll re-enable these analyzers with gopls/v0.5.0, so we'll make sure not to break this test again with that release.

This change is the first step in handling golang/go#38136. Instead of creating multiple diagnostic reports for type error analyzers, we add suggested fixes to the existing reports. To match the analyzers for FindAnalysisError, we add an ErrorMatch function to source.Analyzer. This is not an ideal solution, but it was the best one I could come up with without modifying the go/analysis API. analysisinternal could be used for this purpose, but it seemed to complicated to be worth it, and this is fairly simple. I think that go/analysis itself might need to be extended for type error analyzers, but these temporary measures will help us understand the kinds of features we need for type error analyzers. A follow-up CL might be to not add reports for type error analyzers until the end of source.Diagnostic, which would remove the need for the look-up. Fixes golang/go#38136 Change-Id: I25bc6396b09d49facecd918bf5591d2d5bdf1b3a Reviewed-on: https://go-review.googlesource.com/c/tools/+/226777 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>

myitcv added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. gopls Issues related to the Go language server, gopls. labels Mar 28, 2020

gopherbot added this to the Unreleased milestone Mar 28, 2020

gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Mar 28, 2020

myitcv mentioned this issue Mar 28, 2020

deps: update x/tools and gopls to 09944062 govim/govim#832

Merged

stamblerre modified the milestones: Unreleased, gopls/v0.4.0, gopls/v0.5.0 Mar 30, 2020

myitcv mentioned this issue Apr 2, 2020

cmd/govim: revert skip in signs_unload_load_buffer test govim/govim#839

Closed

stamblerre closed this as completed Apr 2, 2020

stamblerre reopened this Apr 2, 2020

stamblerre closed this as completed Apr 3, 2020

golang locked and limited conversation to collaborators Apr 3, 2021

gopherbot added the FrozenDueToAge label Apr 3, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

x/tools/gopls: duplicate "undeclared name" errors following CL222237 #38136

x/tools/gopls: duplicate "undeclared name" errors following CL222237 #38136

myitcv commented Mar 28, 2020

ridersofrohan commented Mar 30, 2020

myitcv commented Mar 30, 2020

gopherbot commented Mar 30, 2020

ridersofrohan commented Mar 30, 2020 •

edited

myitcv commented Mar 30, 2020

stamblerre commented Mar 30, 2020

gopherbot commented Apr 2, 2020

myitcv commented Apr 2, 2020

stamblerre commented Apr 2, 2020

myitcv commented Apr 2, 2020

leitzler commented Apr 2, 2020

stamblerre commented Apr 2, 2020 •

edited

myitcv commented Apr 2, 2020

stamblerre commented Apr 3, 2020

x/tools/gopls: duplicate "undeclared name" errors following CL222237 #38136

x/tools/gopls: duplicate "undeclared name" errors following CL222237 #38136

Comments

myitcv commented Mar 28, 2020

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

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

ridersofrohan commented Mar 30, 2020

myitcv commented Mar 30, 2020

gopherbot commented Mar 30, 2020

ridersofrohan commented Mar 30, 2020 • edited

myitcv commented Mar 30, 2020

stamblerre commented Mar 30, 2020

gopherbot commented Apr 2, 2020

myitcv commented Apr 2, 2020

stamblerre commented Apr 2, 2020

myitcv commented Apr 2, 2020

leitzler commented Apr 2, 2020

stamblerre commented Apr 2, 2020 • edited

myitcv commented Apr 2, 2020

stamblerre commented Apr 3, 2020

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

What operating system and processor architecture are you using (`go env`)?

ridersofrohan commented Mar 30, 2020 •

edited

stamblerre commented Apr 2, 2020 •

edited