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: prefix in vet output breaks error file format compatibility #34142

Open
mirza-s opened this issue Sep 6, 2019 · 1 comment
Open

cmd/vet: prefix in vet output breaks error file format compatibility #34142

mirza-s opened this issue Sep 6, 2019 · 1 comment

Comments

@mirza-s
Copy link

@mirza-s mirza-s commented Sep 6, 2019

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

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/Users/mbp/go/bin"
GOCACHE="/Users/mbp/Library/Caches/go-build"
GOENV="/Users/mbp/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY="github.com/mirza-s"
GONOSUMDB="github.com/mirza-s"
GOOS="darwin"
GOPATH="/Users/mbp/go"
GOPRIVATE="github.com/mirza-s"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nt/0hzfppd92jvbk99fhvnhy8ph0000gn/T/go-build729502798=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Run

go vet cmd/main.go

What did you expect to see?

cmd/main.go:187:62: undefined: a

What did you see instead?

vet: cmd/main.go:187:62: undeclared name: a

This appears to be introduced in 38431f1

@toothrot
Copy link
Contributor

@toothrot toothrot commented Sep 16, 2019

Hi @mirza-s,

I can confirm this output change locally:

# vet.go
package main

import "fmt"

func main() {
	fmt.Println(a)
}
$ go1.12 vet ./vet.go
# command-line-arguments [command-line-arguments.test]
./vet.go:6:14: undefined: a

$ go vet ./vet.go
# command-line-arguments
vet: ./vet.go:6:14: undeclared name: a

$ go build ~/vet.go 
# command-line-arguments
./vet.go:6:14: undefined: a

I'm not sure if this is a feature or a bug.

/cc @rsc, @josharian and @bradfitz, who have context on the CLs for #31916

Loading

@toothrot toothrot added this to the Unreleased milestone Sep 16, 2019
phlogistonjohn added a commit to phlogistonjohn/samba-operator that referenced this issue Jun 11, 2021
This adds vet as a check in `make check`. Additionally, it moves
the run of vet in `make test` and `make manager` to after the build.
I wanted to remove it entirely from that line but decided not to make
such a big change. Vet needs to run after compile because it prints
a 'vet: ' prefix on compile errors [1], and this messes up tools -
specifically my vim quickfix. Doing the build first makes you fix
real compiler errors and then real vet errors found afterward get
emitted without the annoying prefix.

[1]: golang/go#34142

Signed-off-by: John Mulligan <jmulligan@redhat.com>
phlogistonjohn added a commit to phlogistonjohn/samba-operator that referenced this issue Jun 11, 2021
This adds vet as a check in `make check`. Additionally, it moves
the run of vet in `make test` and `make manager` to after the build.
I wanted to remove it entirely from that line but decided not to make
such a big change. Vet needs to run after compile because it prints
a 'vet: ' prefix on compile errors [1], and this messes up tools -
specifically my vim quickfix. Doing the build first makes you fix
real compiler errors and then real vet errors found afterward get
emitted without the annoying prefix.

[1]: golang/go#34142

Signed-off-by: John Mulligan <jmulligan@redhat.com>
phlogistonjohn added a commit to phlogistonjohn/samba-operator that referenced this issue Jun 12, 2021
This adds vet as a check in `make check`. Additionally, it moves
the run of vet in `make test` and `make manager` to after the build.
I wanted to remove it entirely from that line but decided not to make
such a big change. Vet needs to run after compile because it prints
a 'vet: ' prefix on compile errors [1], and this messes up tools -
specifically my vim quickfix. Doing the build first makes you fix
real compiler errors and then real vet errors found afterward get
emitted without the annoying prefix.

[1]: golang/go#34142

Signed-off-by: John Mulligan <jmulligan@redhat.com>
phlogistonjohn added a commit to phlogistonjohn/samba-operator that referenced this issue Jun 17, 2021
This adds vet as a check in `make check`. Additionally, it moves
the run of vet in `make test` and `make manager` to after the build.
I wanted to remove it entirely from that line but decided not to make
such a big change. Vet needs to run after compile because it prints
a 'vet: ' prefix on compile errors [1], and this messes up tools -
specifically my vim quickfix. Doing the build first makes you fix
real compiler errors and then real vet errors found afterward get
emitted without the annoying prefix.

[1]: golang/go#34142

Signed-off-by: John Mulligan <jmulligan@redhat.com>
phlogistonjohn added a commit to samba-in-kubernetes/samba-operator that referenced this issue Jun 18, 2021
This adds vet as a check in `make check`. Additionally, it moves
the run of vet in `make test` and `make manager` to after the build.
I wanted to remove it entirely from that line but decided not to make
such a big change. Vet needs to run after compile because it prints
a 'vet: ' prefix on compile errors [1], and this messes up tools -
specifically my vim quickfix. Doing the build first makes you fix
real compiler errors and then real vet errors found afterward get
emitted without the annoying prefix.

[1]: golang/go#34142

Signed-off-by: John Mulligan <jmulligan@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants