Comment 1:

type-checking cgo program is not easy, we will need first call "go build -work" to get
cgo-generated Go source files before type-checking, perhaps we could just make
go/types ignore import "C".

Comment 3:

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 4 by rnd0x00:

Related to this issue is the following example.
b.go located at: http://play.golang.org/p/dyr3_PAwhl
[~]$ go vet b.go
b.go:10: arg for printf verb %s of wrong type: invalid type
exit status 1
The error is no longer "could not import C (can't find import: C)", but instead an
inaccurate vetting error.

Comment 5:

also saw this:
foo.go:374: %!s(<nil>) composite literal uses untagged fields
foo.go:376: %!s(<nil>) composite literal uses untagged fields
those lines have:
maxwait := C.struct_timeval{1, 500 * 1000}
poll := C.struct_timeval{0, 10 * 1000}

Comment 6:

I think my issue probably just got fixed:
https://code.google.com/p/go/source/detail?r=eb28a75cdc403bcb2ba0210893494ca8a71c6e1e

Comment 7:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

Comment 8:

Labels changed: added go1.2maybe.

Comment 9:

Labels changed: added feature.

Comment 10:

A number of the examples in this issue work now because they were unrelated to the main
topic. Recent changes have made go vet more robust and accurate even when typechecking
fails.
Top example:
z.go:7: arg 5 for printf verb %s of wrong type: int
Second example: silence.
Deferring to 1.3; the cgo issue that is the real one here remains hard.

Labels changed: added go1.3maybe, removed go1.2maybe.

Comment 11:

Labels changed: removed go1.3maybe.

Comment 12:

Labels changed: added go1.3maybe.

Comment 13:

Labels changed: removed feature.

Comment 14:

Labels changed: added release-none, removed go1.3maybe.

Comment 15:

Labels changed: added repo-tools.

Close the issue for now as it has remained inactive for more than 6 months.

Anyone with more insight into the current status may re-open the issue or add a comment about the current progress.

I thought @mdempsky was still interested in this.

I thought @mdempsky was still interested in this.

Matthew, you may re-open this issue if you are still interested in it. I decided to close it, as it had been placed in the Go "black hole" that is the unreleased milestone.

Didn't mean to close it if you still had an interest in it.

Cheers /u

@mewmew, "unreleased" doesn't mean blackhole. It means it's not shipped with Go so it can be fixed at any point. But now that vet is part of the standard library, Unreleased is no longer appropriate.

See also: #16623

Change https://golang.org/cl/74750 mentions this issue: cmd/go: pass package config to vet during "go vet"