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

cmd/vet: failure to load "fmt" causes spurious fmt.Stringer errors #13168

Closed
alandonovan opened this issue Nov 5, 2015 · 3 comments

Comments

Projects
None yet
4 participants
@alandonovan
Copy link
Contributor

commented Nov 5, 2015

% cat stringer.go
package p

import "fmt"

type S struct {
_ func() // not printable with %s
}

func (S) String() string

var _, _ = fmt.Printf("%s", S{})

% vet ./stringer.go

% GOROOT=/nosuchdir vet ./stringer.go
vet: import failed: can't find import: fmt
vet: import failed: can't find import: fmt
./stringer.go:11: arg S{} for printf verb %s of wrong type: p.S

David, I believe this is the root cause of internal bug #13114430. We might want to create the stringerType interface from whole cloth instead of loading it. Or not; perhaps this bug is too obscure.

@dsymonds

This comment has been minimized.

Copy link
Member

commented Nov 5, 2015

fmt.Stringer is certainly a trivial enough type, yet central enough to vet's operation that it seems correct to manifest it within vet. I'm not sure how to do that, but happy to review a CL from you.

@dsymonds dsymonds assigned alandonovan and unassigned dsymonds Nov 5, 2015

@ianlancetaylor ianlancetaylor changed the title vet: failure to load "fmt" causes spurious fmt.Stringer errors cmd/vet: failure to load "fmt" causes spurious fmt.Stringer errors Nov 5, 2015

@alandonovan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 5, 2015

Correction: internal bug 22881152. I've posted a response there.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2015

Quoting Alan's comment on the internal bug:

We could "fix" this by changing the external tool, but that's unsatisfactory for two reasons. (1) External users are very unlikely to encounter this problem because their GOROOT will be either unset or set to a valid directory. Effectively we'd be adding a bizarre new invariant to the external code base, namely that the tool must work without access to the standard library. (2) Even if we hand-code the Stringer type, the tool has dependencies on other standard types like fmt.Formatter that mention named types, and it may grow more in the future. The same workaround won't work for them.

So I think the right place for the fix is in [our internal tools, to set GOROOT correctly.].

Closing this.

@rsc rsc closed this Dec 28, 2015

@golang golang locked and limited conversation to collaborators Dec 29, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.