This seems to be related to unexported interface fields - this is a smaller reproducer:

package main

import "fmt"

type T1 struct {
        t2 interface{}
}

func main() {
        v := T1{"foo"}
        fmt.Printf("%s\n", v)
}

Change https://golang.org/cl/90516 mentions this issue: cmd/vet: unexported interface fields on %s are ok

I'm going to redirect this to 1.10 because with 1.10 this occurs when running go test as well as when running go vet.

@ianlancetaylor please see all the other recent vet issues that OP raised. These could all be considered regressions in 1.10, given how vet is now run as part of test. I have sent CLs for 4 of these already.

As I more or less said on the CL, I'm not yet convinced that this is a bug. The right way to print a value of type error is to call the Error method. It's true that in this case fmt does the best it can and just prints the value, but I think that is not what people would reasonably expect. People would reasonably expect a call to the Error method. So this does seem worthy of a vet warning.

CC @robpike @martisch for other opinions.

@ianlancetaylor you may be right. However, note that my CL affects all interfaces, not just error and fmt.Stringer. Perhaps the CL should keep the warning for those types.

Edit: what I mean is that vet could warn on struct { f errorImpl } and struct { f error }, but not on struct { f interface{} } and any other field type that doesn't imply error or fmt.Stringer.

@mvdan Is that not how it works today?

@ianlancetaylor not exactly - see my full example in #23563 (comment). The t2 interface{} field gets flagged, when the user couldn't reasonably expect String() string or Error() string to be present.

So I agree that OP's example is working as intended (even if the program technically works), but I think that the current heuristic is too aggressive. It should only cover types that we know to have String or Error.

Thanks, that sounds reasonable. I guess we should also warn about uncallable Format and GoString methods.