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

Jump to bottom

go/parser: inconsistent error messages when missing braces after struct/interface in return type #36595

Open
zikaeroh opened this issue Jan 16, 2020 · 2 comments
Open

go/parser: inconsistent error messages when missing braces after struct/interface in return type #36595

zikaeroh opened this issue Jan 16, 2020 · 2 comments
Labels
gopls/parsing Issues related to parsing / poor parser recovery. NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unreleased

Comments

@zikaeroh
Copy link
Contributor

Please answer these questions before submitting your issue. Thanks!

What did you do?

Three files. what.go:

package what

func doSomething() {
	var s SomeStruct
	_ = s.StringAbove()
	_ = s.StringBelow()
}

type SomeStruct struct {
	readyChan chan struct{}
}

// StringAbove is a function above ready().
func (s *SomeStruct) StringAbove() string {
	return "SomeStruct"
}

func (s *SomeStruct) ready() chan struct{} {
	return s.readyChan
}

// StringBelow is a function below ready()
func (s *SomeStruct) StringBelow() string {
	return "SomeStruct"
}

type OtherType struct {
	v string
}

func (o OtherType) String() string {
	return o.v
}

what_test.go

package what_test

import (
	"testing"
	"what"
)

func TestSomething(t *testing.T) {
	var s what.SomeStruct
	_ = s.StringAbove()
	_ = s.StringBelow()
}

func TestOther(t *testing.T) {
	var o what.OtherType
	_ = o.String()
}

what_test2.go

package what

import (
	"testing"
)

func TestSomething2(t *testing.T) {
	var s SomeStruct
	_ = s.StringAbove()
	_ = s.StringBelow()
}

func TestOther2(t *testing.T) {
	var o OtherType
	_ = o.String()
}

Now, remove the {} after struct in ready's return value.

What did you expect to see?

Preferably, recovery from this situation (that might be another issue about how to deal with these parsing issues), and consistent-ish diagnostics with the issue.

What did you see instead?

No recovery, so everything that comes after is broken. But, it's only for that one type, and the diagnostics / hover behavior of things is pretty inconsistent.

A screencast: https://streamable.com/xc1k0

https://gist.github.com/zikaeroh/e752451719bff6020ba8a981678c9184

Build info

golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@v0.1.8-0.20200116062425-473961ec044c h1:1TIoDnmETx0ZptB3IkN+lN1z/gkfEtlCEjQmD51vhsM=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/go-diff@v1.0.0 h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ=
    golang.org/x/mod@v0.1.1-0.20191105210325-c90efee705ee h1:WG0RUwxtNT4qqaXX3DPA8zHFNm/D9xaBpxzHt1WcA/E=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20200116062425-473961ec044c h1:D0OxfnjPaEGt7AluXNompYUYGhoY3u6+bValgqfd1vE=
    golang.org/x/xerrors@v0.0.0-20191011141410-1b5146add898 h1:/atklqdjdhuosWIl6AIbOeHJjicWYPqR9bpxqxYG2pA=
    honnef.co/go/tools@v0.0.1-2019.2.3 h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM=
    mvdan.cc/xurls/v2@v2.1.0 h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=

Go info

go version go1.13.6 linux/amd64

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jake/.cache/go-build"
GOENV="/home/jake/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jake/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jake/testproj/what/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-build340140430=/tmp/go-build -gno-record-gcc-switches"
@gopherbot gopherbot added this to the Unreleased milestone Jan 16, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Jan 16, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.3.0, Unplanned, gopls unplanned Jan 16, 2020
@stamblerre stamblerre modified the milestones: gopls unplanned, gopls/v1.0.0 Jan 29, 2020
@golang golang deleted a comment from gopherbot Mar 12, 2020
@stamblerre
Copy link
Contributor

Thanks for the report. This fits into a common pattern with go/parser, which is that it fails to recover and causes all symbols defined below the breakage to become undefined. I'm not sure if this is something that will be fixed anytime soon in the parser, but I will file this issue under go/parser.

@stamblerre stamblerre changed the title x/tools/gopls: inconsistent diagnostics when missing braces after struct/interface in return type go/parser: inconsistent error messages when missing braces after struct/interface in return type Mar 12, 2020
@stamblerre stamblerre removed Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Mar 12, 2020
@stamblerre stamblerre modified the milestones: gopls/v1.0.0, Unreleased Mar 12, 2020
@toothrot toothrot added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 13, 2020
@gopherbot
Copy link

Change https://golang.org/cl/259817 mentions this issue: go/parser: Improve error when interface or struct parsing fails

@adonovan adonovan mentioned this issue Mar 2, 2023
Open
@adonovan adonovan added the gopls/parsing Issues related to parsing / poor parser recovery. label Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
gopls/parsing Issues related to parsing / poor parser recovery. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@toothrot @adonovan @stamblerre @gopherbot @zikaeroh