A challenge with vet is that it cannot assume it has correct or indeed any type information for imported packages. Consequently, there's a fine balance to be struck between using syntax information, using type information that can be relied upon because it's local to a file, and using type information from dependencies, which is likely to be absent for all non-standard packages. The way go/types represents dangling aliases, that is, aliases to members of packages for which no type information is available, does not tell us even the name of the missing thing, so using aliases here would make the tool less robust.

In the specific case of context.WithCancel, it's likely that the various clones of the context package (the standard one, the one in golang.org/x/net, and Google's original one) may use aliases to smooth over their differences, but probably all clients will access the WithCancel function using a qualified identifier, context.WithCancel, for some unspecified import that defines context. This check's apparent sloppiness about matching the package name was a conscious and deliberate choice.

Here's a list of uses of selector expressions in vet:

• atomic: uses package name == "atomic"
• cgo: uses package name == "C"
• lostcancel: uses package name == "context"
• nilfunc: looking for any functions whatsoever
• print: looking for any functions whatsoever
• tests: only checks selector, not package name
• unsafeptr: uses t.Obj().Pkg().Path() == "reflect"
• unused: uses obj.Pkg().Path()

The ones that use package name directly are probably fine, per Alan's comments above. It seems fairly likely that packages atomic, C, and context won't be aliased away.

For unsafeptr, unsafe can't be aliased, and reflect probably won't be.

It might be better for unused to use package name rather than obj.Pkg().Path(), although the packages that matter out of the box (errors, fmt, sort) are unlikely to be aliased. Leaving that decision to Alan.

That's all I see from a first visual inspection of vet. Alan, if you're happy, feel free to close this, and we'll deal with other specific issues as they come up in testing.

For the record, I audited every go/ast-using package in the standard library and fixed the important ones where aliases could lead to a crash or incorrect results, but there are rapidly diminishing returns to worrying about aliases in these vet checks. Standard packages are, I suspect, unlikely to be the targets of aliases, and vet has a very fragmentary view of things outside the few files it analyzes.