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 range for function with missing return is the entire function body #35139

Closed
zikaeroh opened this issue Oct 24, 2019 · 7 comments
Labels
Milestone

Comments

@zikaeroh
Copy link

@zikaeroh zikaeroh commented Oct 24, 2019

Please answer these questions before submitting your issue. Thanks!

What did you do?

Wrote a somewhat large function by coping incomplete code from somewhere else. It's missing the return at the end. Like:

func (b *Bot) loadRepeats(reset bool) error {
	repeats, err := models.RepeatedCommands(
		models.RepeatedCommandWhere.Enabled.EQ(true),
	).All(ctx, b.db)
	if err != nil {
		return err
	}

	updateRepeating(b.deps, repeats, true)

	scheduleds, err := models.ScheduledCommands(
		models.ScheduledCommandWhere.Enabled.EQ(true),
	).All(ctx, b.db)
	if err != nil {
		return err
	}

	updateScheduleds(b.deps, scheduleds, true)

}

What did you expect to see?

A reasonable squiggle that shows me where the issue is.

What did you see instead?

The error range for this parser error is the entire function body:

image

I spent way too much time trying to figure out what was actually wrong with this function after pasting the code (I thought there may have been a file content desync), only to see that it's just missing a return.

This is probably related to the fix for #29150 that was recently merged. Previously, I believe the diagnostic range for this was just the location of the opening curly brace, but now it's the range of the function.

I'm not sure what a better place would be to hint that something is wrong (The end of the function where a return is missing? The return type declaration? The function name?), but the current behavior seems not so good to me.

Build info

golang.org/x/tools/gopls v0.1.6
    golang.org/x/tools/gopls@v0.1.8-0.20191024172055-b24f3822ec91 h1:H8QicEu7VP3ZTPouxMPP05TSLST6k+ALFGshzp0KRi8=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/go-diff@v1.0.0 h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20191024172055-b24f3822ec91 h1:NvY90D3CbHVmVqqJM90znmY6JIpjBtB1RE1m+ozuods=
    golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7 h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc=
    honnef.co/go/tools@v0.0.1-2019.2.3 h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM=

Go info

go version go1.13.3 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/zikaeroh/hortbot/hortbot/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-build311746156=/tmp/go-build -gno-record-gcc-switches"
@gopherbot gopherbot added this to the Unreleased milestone Oct 24, 2019
@gopherbot gopherbot added the Tools label Oct 24, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Oct 24, 2019

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

@gopherbot gopherbot added the gopls label Oct 24, 2019
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Oct 24, 2019

Thanks for the report. Caused by CL 202542. I will probably revert some of the changes in that CL soon.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Oct 25, 2019

Change https://golang.org/cl/203287 mentions this issue: internal/lsp: ensure diagnostics never highlight a full function body

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Oct 25, 2019

CL 203287 will address this by highlighting only the function name. There is definitely a lot more work to be done here though. If we were able to match on the error type, we could specifically show an error on the ending curly brace, or something like that.

@zikaeroh

This comment has been minimized.

Copy link
Author

@zikaeroh zikaeroh commented Oct 25, 2019

Thanks for taking a look. I checked out the CL and applied it to see, but it appears as though the function bodies are still getting squiggled when the function is missing a return case.

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Oct 25, 2019

Thank you for checking that! I forgot that I had added a special case for that file to skip checking ranges on diagnostics 🤦‍♀It should work now.

@zikaeroh

This comment has been minimized.

Copy link
Author

@zikaeroh zikaeroh commented Oct 25, 2019

It works, now, thanks. 😄

@stamblerre stamblerre closed this Nov 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.