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: could not import C error when used with -v #21188

Closed
mvdan opened this issue Jul 27, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@mvdan
Copy link
Member

commented Jul 27, 2017

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

go version devel +45a4609c0a Thu Jul 27 05:04:28 2017 +0000 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mvdan/go/land:/home/mvdan/go"
GORACE=""
GOROOT="/home/mvdan/tip"
GOTOOLDIR="/home/mvdan/tip/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build516844053=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

package main

import "C"

func main() {}
 $ go vet
 $ go vet -v
vet: bug.go:3:8: could not import C (can't find import: "C")
Checking file bug.go
exit status 1

What did you expect to see?

Success, even with -v.

What did you see instead?

The unexpected import error.

go vet -v doesn't have this issue on 1.8.3, so I'm marking as a release blocker for 1.9.

Something to note is that the catalyst for this bug was the fix for #19350 by @robpike. In 1.8, when running go vet -v, the verbose flag wasn't passed to go tool vet, and the bug was hidden away.

But if we run the tool manually in both 1.8.3 and master, it's broken on both:

 $ go tool vet -v .
vet: bug.go:3:8: could not import C (can't find import: "C")
Checking file bug.go
 $ go1 tool vet -v .
vet: bug.go:3:8: could not import C (can't find import: )
Checking file bug.go

The obvious, faster option is to revert 62aeb77. Given that we have a bit of time left until 1.9 is supposed to go out, I'll poke around go tool vet to see if I can fix the bug there.

@mvdan

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2017

To clarify - go vet -v on 1.8.3 doesn't actually enable the verbose option, so it doesn't have the Checking file... lines either. Reverting the commit would essentially be replacing one bug with another.

@mvdan

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2017

What I've found so far - the reason that -v makes it fail is this:

// Type check the package.
err := pkg.check(fs, astFiles)
if err != nil && *verbose {
        warnf("%s", err)
}

Should -v affect whether vet returns exit code 0 or 1? That seems unexpected.

And it seems like the underlying cause is go/importer and go/types not playing well with import "C". So perhaps the underlying bug is just a dup of #6774.

I still see the change in behavior as a regression, though. An error that was being ignored is now being surfaced by -v, changing whether go vet is happy or not.

Edit: I did not intend to mark this issue as a duplicate.

@mvdan mvdan marked this as a duplicate of #6774 Jul 27, 2017

@josharian

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2017

Maybe warnf shouldn't cause vet to return 1.

@mvdan

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2017

It certainly seems that way, given the name. That fix would be ok for 1.9, as far as I'm concerned.

@josharian

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2017

Here's where I pass the buck. :)

Maybe warnf shouldn't cause vet to return 1.

It certainly seems that way, given the name.

This decision belongs to @robpike.

That fix would be ok for 1.9, as far as I'm concerned.

That call is above my pay grade. @bradfitz or @ianlancetaylor?

@robpike

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2017

I can't speak to the underlying issue in the importer. That should be fixed.

But I do believe that the exit code should be 1. The purpose of warnf is to report an error but not exit the program, as further tests are possible. It indicates a problem, in this case that it can't import one of the packages, and so vet cannot say that there are no errors in the program.

In short, warnf should cause an exit with code 1. Vet should exit with 0 only when the whole program has been checked successfully and without problems.

@mvdan

This comment has been minimized.

Copy link
Member Author

commented Jul 28, 2017

That call is above my pay grade.

Oh, above mine too - I was simply giving my opinion :)

But I do believe that the exit code should be 1.

My point here was not so much whether an import error should make the program fail, or whether a warning should make it fail. It was more the fact that -v is changing the exit code. Depending on whether you were using go vet with -v on your CI with 1.8.x, it will suddenly break for no good reason when upgrading to 1.9rc1 (this is what happened to us).

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 28, 2017

The purpose of warnf is to report an error but not exit the program,

Doesn't that imply that warnf calls should never be conditional on the verbose flag? It seems strange to detect an error that indicates a real problem but not to report it.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2017

The vet tool runs the type checker in go/types. The warning being reported is a type checking failure. We only report that warning when using -v, because vet is supposed to work on packages that do not type check. So as @bcmills suggests I think that this output is best characterized as not being a warning. I will send a CL.

@gopherbot

This comment has been minimized.

Copy link

commented Aug 2, 2017

Change https://golang.org/cl/52851 mentions this issue: cmd/vet: don't exit with failure on type checking error

gopherbot pushed a commit that referenced this issue Aug 3, 2017

cmd/vet: don't exit with failure on type checking error
The vet tool only reports a type checking error when invoked with -v.
Don't let that by itself cause vet to exit with an error exit status.

Updates #21188

Change-Id: I172c13d46c35d49e229e96e833683d8c82a77de7
Reviewed-on: https://go-review.googlesource.com/52851
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2017

Fixed for 1.9, opened #21287 for 1.10.

@golang golang locked and limited conversation to collaborators Aug 3, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.