Alan Donovan

> And each returned package should already have SetImports (and flattenImports) called by time r.pkg() returns. > In your scenario, are {a,b,c} all being created/loaded from export data, or have...

The ones from last week are just "signal: segmentation fault" with no further information, which makes me suspect a problem with the builder or Go toolchain rather than the x/tools...

Closing due to age.

I agree it's harder. For unexported vars it only requires looking at a single type-checked package but that's still a lot more work than hover needs to do in the...

This feature would first need to be added to x/tools/go/packages, which the multichecker driver uses for package information. So let's expand this proposal to consider the API changes to both...

A utility analyzer is overkill; we should just get the API right. The client needs to know "is this file a test file?" or, more often, "is this node or...

> I think what I'm trying to say is: is there a reason to duplicate this information? Anything "input" data exposed by analysis.Pass interface needs to be derivable from packages.Package,...

> func (pass *Pass) InTestFile(pos token.Pos) bool The interface I proposed above assumes that files are parsed (which is the common use-case for go/packages, but isn't actually required), so this...

> Maybe I got confused by @timothy-king comment above but are you now suggesting a solution that does not involve adding this information to go/types? I wasn't suggesting that go/types...

> I think a analysis only solution is appropriate here. See my note in https://github.com/golang/go/issues/65749#issuecomment-1956808531: it has to be in both go/analysis and go/packages.