While writing this up (this is an issue I discovered long ago and added it to my TODO list to report it) just now, I investigated further and found out why it happens.

You may or may not be able to reproduce it in your setup if you follow the steps above. It may be an issue or it may be working as intended.

Cause

The reason vet did not catch the thirdParty.ClientID bad printf usage case is because I had the third party package source only, but it wasn't installed (no entry in $GOPATH/pkg). Running it with -v option displays a warning message:

vet: main.go:8:2: could not import golang.org/x/oauth2 (can't find import: golang.org/x/oauth2)
Checking file main.go
main.go:21: arg stdLib.Path for printf verb %d of wrong type: string

So, I could do go run main.go on that file because go run and go build will build all packages that are not installed from source on demand. (Due to unrelated complicated reasons, I tend to have very few packages installed and rely on go build always building everything from source.)

After I did go install golang.org/x/oauth2, running vet produced expected results.

Possible solutions

I see two possible solutions:

1. Either make vet behave more intelligently like go build and go run, if the source is present but compiled package is missing, build it temporarily on demand or process the source instead. This way vet will always work reliably.

2. Right now vet is not 100% reliable because it may or may not work depending on whether you have some packages installed. However, the exit code is 1 regardless whether:

   • vet ran successfully, processed all files and found some issues to report,
   • vet did not run successfully due to packages not being installed or missing source.

   There should be some (machine-readable) way to distinguish a failed vet run vs. a successful run that found issues.

I think fixing point 2 is easy and should be done. Fixing point 1 may be too complicated and not worth it.

In fact, running vet with the entire golang.org/x/oauth2 package missing (no source, no installed) - so that even go build would fail - still results in the exact same incomplete output and exit code 1.

2. Right now vet is not 100% reliable because it may or may not work depending on whether you have some packages installed. However, the exit code is 1 regardless whether:

• vet ran successfully, processed all files and found some issues to report,
• vet did not run successfully due to packages not being installed or missing source.

There should be some (machine-readable) way to distinguish a failed vet run vs. a successful run that found issues.

Actually, that might not be correct.

What's most important is that there is always a (machine-readable) way to distinguish between these 2 cases:

1. A successful vet run that found 0 issues,
2. Either successful run that detected 1 or more issues or failed to check everything because of missing packages.

And I think that's currently the case. The exit code from vet seems to be always 1 even if it found no issues, but failed to import some package (meaning there may be issues found once package is successfully imported).

So, as long as you get exit code 0 with no output, you can be sure there are no vet issues. If you get exit code 1, you need to investigate (even if there is no output, no errors caught) until the exit code becomes 0.

If that's really the case, then this is likely a non-issue. While it would be nice if vet could be more capable at loading/processing packages from source only and display issues right away, it's not critical as long as it can be reliably used to verify there are no issues. I'll let you decide what should be done or if this can be closed.

I think it's working as intended.

However, I do want to propose we make the "couldn't load import" message visible
without -v, at least as a warning.

However, I do want to propose we make the "couldn't load import" message visible
without -v, at least as a warning.

I agree with that.

I've updated the issue title to reflect the latest status of this issue.

Everything is working as intended, except that the "could not import" warning message should be displayed even if -v is not specified, otherwise the output can be visually misleading. The non-zero exit status is less visible to humans.

I'm interested in working on this as this behaviour of govet caused me some confusion recently.

I did some digging. The way this fails is:
cmd/vet/main.go: doPackage creates a local Package and calls check() on it
cmd/vet/types.go: (*Package).check() creates go/types.Config and calls Check(). Check ultimately returns an error when the import fails. There isn't a good way to determine an import failure from any other type of error from Check.

When check() creates types.Config, it builds it with importer.Default(). This provides a convenient hook pass a wrapped Importer/ImporterFrom, one that delegates all calls but collects failure evidence.

check() could then update the local Package with failed imports, which would then be available to go vet for error reporting. I would suggest keeping a map[string]bool in the package var and reporting any failed imports at the end. E.g:

if len(failedImports) > 0 {
warnf("unable to import the following packages, go install them and rerun: ...")
}

I could have a CL for this in a few days if this SG.