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

go/types: improve error message quality for ptr receiver errors (go/types differs from go tool compile) #36336

Closed
gertcuykens opened this issue Dec 31, 2019 · 3 comments
Assignees
Milestone

Comments

@gertcuykens
Copy link
Contributor

@gertcuykens gertcuykens commented Dec 31, 2019

In this particular case go build has a vastly better error message, assuming it's not vscode but gopls who is responsible for altering the original compile message.

type roundTripper func(*http.Request) (*http.Response, error)

func (f roundTripper) RoundTrip(req *http.Request) (*http.Response, error) { return f(req) }

func proxy(u url.URL) http.Handler {
	return httputil.ReverseProxy{
		Transport: roundTripper(func(req *http.Request) (*http.Response, error) {
			req.Header.Set("Host", u.Host)
			return http.DefaultTransport.RoundTrip(req)
		}),
		Director: func(req *http.Request) {
			req.URL.Scheme = u.Scheme
			req.URL.Host = u.Host
			req.Header.Set("Host", u.Host)
		},
	}
}

image

gopls:

cannot use (httputil.ReverseProxy literal) (value of type httputil.ReverseProxy) as http.Handler value in return statement: missing method ServeHTTP compiler

original go build compiler message:

cannot use httputil.ReverseProxy literal (type httputil.ReverseProxy) as type http.Handler in return argument:
        httputil.ReverseProxy does not implement http.Handler (ServeHTTP method has pointer receiver)
@gopherbot gopherbot added this to the Unreleased milestone Dec 31, 2019
@golang golang deleted a comment from gopherbot Jan 2, 2020
@muirdm
Copy link

@muirdm muirdm commented Jan 2, 2020

gopls uses the go/types package, not the compiler, to type check. go/types doesn't provide as useful of an error message in this situation. It can probably be improved but would be subject to the Go release cycle (rather than gopls).

/cc @griesemer

Loading

@stamblerre stamblerre removed this from the Unreleased milestone Jan 2, 2020
@stamblerre stamblerre added this to the gopls unplanned milestone Jan 2, 2020
@stamblerre stamblerre changed the title x/tools/gopls: does not implement x (x method has pointer receiver) x/tools/gopls: improve error message quality (go/types differs from go build) Jan 2, 2020
@griesemer griesemer changed the title x/tools/gopls: improve error message quality (go/types differs from go build) go/types: improve error message quality for ptr receiver errors (go/types differs from go tool compile) Jan 2, 2020
@griesemer griesemer self-assigned this Jan 2, 2020
@griesemer griesemer removed this from the gopls unplanned milestone Jan 2, 2020
@griesemer griesemer added this to the Go1.15 milestone Jan 2, 2020
@griesemer
Copy link
Contributor

@griesemer griesemer commented Jan 2, 2020

This is a go/types, not a gopls issue. Stand-alone test case: https://play.golang.org/p/LAbt1say8h2

The compiler reports:
./prog.go:14:30: cannot use httputil.ReverseProxy literal (type httputil.ReverseProxy) as type http.Handler in return argument: httputil.ReverseProxy does not implement http.Handler (ServeHTTP method has pointer receiver)

go/types reports:
./prog.go:14:9: cannot use (httputil.ReverseProxy literal) (value of type httputil.ReverseProxy) as http.Handler value in return statement: missing method ServeHTTP

It should not be too hard to make the go/types error better.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 24, 2020

Change https://golang.org/cl/229801 mentions this issue: go/types: improve error message for pointer receiver errors

Loading

@gopherbot gopherbot closed this in 512277d Apr 24, 2020
xujianhai666 added a commit to xujianhai666/go-1 that referenced this issue May 21, 2020
The compiler produces high quality error messages when an interface is
implemented by *T, rather than T. This change improves the analogous
error messages in go/types, from "missing method X" to "missing method
X (X has pointer receiver)".

I am open to improving this message further - I didn't copy the compiler
error message exactly because, at one of the call sites of
(*check).missingMethod, we no longer have access to the name of the
interface.

Fixes golang#36336

Change-Id: Ic4fc38b13fff9e5d9a69cc750c21e0b0c34d85a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/229801
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
@golang golang locked and limited conversation to collaborators Apr 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants