Alan Donovan

> Right, but IsInt64 and IsUint64 report inexactness — so folding them into a single method call seems more like a performance optimization than an API necessity. Fair enough. Let's...

Anyone else object to the reduced proposal?

The proposed implementation in https://go.dev/cl/453115 is ready for review.

Using VSCode with gopls v0.11.0, I confirm the problem reported in this issue. Specifically, I used a `new` subpackage of golang.org/x/tools and was unable to get struct field completions for...

Many thanks @joeshaw for taking the time to find a minimal testcase; I confirm that it reproduces the panic for me at tip today. A brief investigation makes me suspect...

> Alan do you recall if something is being more conservative during package loading than it used to? No, I suspect there has always been a latent problem here with...

Just because the bug appeared at 1.19 doesn't mean go list is at fault: it could just be that the reference structure of the program evolved and now there is...

Using Tim's reduced testcase, the import graph of interest is ``` main ⟶ net/http ⟶ crypto/tls ⟶ crypto/x509 ⟶ crypto/x509/pkix ``` I observe that the Packages.Imports list for net/http includes...

Even more minimal testcase: Target program: ``` xtools$ head $(find minim2 -type f) ==> minim2/minim2.go minim2/a/a.go minim2/b/b.go minim2/c/c.go a -> b -> c`. As @mdempsky said, the `Packages.Import` list with...

I suspect a bug in [flattenImports](https://cs.opensource.google/go/x/tools/+/master:internal/gcimporter/ureader_yes.go;l=284?q=flattenImports&ss=go%2Fx%2Ftools) in the go1.20 unified export data reader: it assumes that Packages.Imports of each of its direct dependencies is already set. But consider `minim2 ->...