Navigation Menu

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

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

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

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

alandonovan opened this issue Nov 5, 2015 · 3 comments
Labels
FrozenDueToAge

Comments

@alandonovan
Copy link
Contributor

% 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
Copy link
Contributor

dsymonds 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
Copy link
Contributor Author

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

@rsc
Copy link
Contributor

rsc 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 as completed 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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dsymonds @rsc @alandonovan @gopherbot