cmd/vet: some change in behavior since Go 1.6

[runningmaster]

1 What version of Go are you using (go version)?

$ go version
go version devel +2330ae8 Fri Mar 18 12:30:39 2016 +0000 linux/amd64

2 What operating system and processor architecture are you using (go env)?

$go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/dmitriy/Development/govettest"
GORACE=""
GOROOT="/home/dmitriy/Development/go"
GOTOOLDIR="/home/dmitriy/Development/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build781365758=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

3 What did you do?

I made mini test (note: dir govettest == $GOPATH):

[dmitriy@n403 govettest]$ tree
.
├── bin
│   └── main
├── pkg
│   └── linux_amd64
│       └── internal
│           └── version.a
└── src
    ├── internal
    │   └── version
    │       ├── gen.go
    │       └── version.go
    └── main
        └── main.go

[dmitriy@n403 main]$ cat main.go 
package main

import (
    "fmt"
    "internal/version"
)

func main() {
    fmt.Println(version.Test())
}

[dmitriy@n403 version]$ cat gen.go 
// +build ignore

package main

// some code here

[dmitriy@n403 version]$ cat version.go 
//go:generate go run gen.go

package version

import "fmt"

func Test() string {
    return fmt.Sprintf("%s+%s.%s", "version", "buildtime", "gitcommit")
}

Finally

$ cd src/internal/version
$ go tool vet ./*.go

4 What did you expect to see?

Silent output.

5 What did you see instead?

./version.go:8: no formatting directive in Sprintf call

NOTE

1. All works fine in last release go version go1.6 linux/amd64
2. Also all OK after delete gen.go from package folder internal/version

[bradfitz]

Does the // some code here in gen.go matter?

This might be user error. The docs says:

        vet [flags] files... # Must be a single package

You're passing files, but one is "package main" and one is "package version".

[runningmaster]

@bradfitz

Does the // some code here in gen.go matter?

No, it doesn't. But full file version is here.

You're passing files, but one is "package main" and one is "package version".

Yes, I am. But these two files belong to single package by sense. There is the same situation in go. For example, package x509 and others.

[bradfitz]

Yes, I am. But these two files belong to single package by sense. There is the same situation in go. For example, package x509 and others.

But in those cases, the go/build rules dictate how the files are selected, and the +build ignore rules are used. In this case, you're specifying the files explicitly.

[valyala]

This may be related to #14754 .

[runningmaster]

@bradfitz

Thank you for help.

In this case, you're specifying the files explicitly.

I understand, but then how does to do single separate package that contains its "native" source files ("package version") with executable source file(s) for go:generate mechanism ("package main" )?

It seems naturally for me and I placed these files together in one package.

In any case for go1.6 this way worked good (for me).

[bradfitz]

I don't know what the right answer is here. I was just reading the code & docs for the first time.

[runningmaster]

@bradfitz

vet [flags] files... # Must be a single package

I found this problem when I used gometalinter on my project. I looked how it calls vet. Therefore I made my test with same call.

[fsouza]

I have been facing this issue with go-dockerclient as well: https://travis-ci.org/fsouza/go-dockerclient/jobs/115602473#L326. It fails only on tip.

[valyala]

@runningmaster , @fsouza , does the issue still exist after the #14754 is fixed?

[fsouza]

@valyala nope, it seems to be gone, thank you!

[rsc]

Seems to be fixed.