Use upstream definitions, fix gopackagesdriver #4185
Conversation
|
It looks like this CI failure: https://buildkite.com/bazel/rules-go-golang/builds/7281#019373f5-722b-4160-8e7b-4cdc32943756 is unrelated to this PR. Going to ignore it for now. |
|
Cc @JamyDev |
| Imports: imports, | ||
| } | ||
|
|
||
| // TODO(ellie): wtf why does this fix things |
There was a problem hiding this comment.
My guess would be here:
rules_go/go/tools/builders/stdliblist.go
Line 275 in e8adba2
pure (i.e. no cgo)
There was a problem hiding this comment.
Just checked - this was why this was actually broken.
There was a problem hiding this comment.
Hmmm.. Okay, so. The problem with enabling -compiled is that it kicks off a really intensive build of every cgo file in the standard library - as seen by why the latest CI run is failing. I'm not convinced that this is actually the best fix either. (see: golang/go#29427)
|
What else would be needed here to get this landed? |
I'm not sure. At @devzero-inc, we use this patch-set daily, and I know that it definitively works for us, but we also have an entirely cgo-free code base. Earlier, at @fmeum's request, I tried to dig into /why/ specifically CompiledGoFiles isn't getting populated, and experimented with passing |
What type of PR is this?
Bug fix
Feature
What does this PR do? Why is it needed?
With some recent changes made, the gopackagesdriver seems to fail to resolve all standard library imports. This fixes that, as well as migrating the driver to use the upstream definitions as defined here: https://pkg.go.dev/golang.org/x/tools/go/packages#hdr-The_driver_protocol.
Which issues(s) does this PR fix?
Fixes #4184
Fixes #3962
Other notes for review
This is absolutely not fully ready to be merged in. I'm willing to take some time to clean this diff up, but would like some guidance on what specifically should be changed / what should be kept. Please let me know, and be patient with me here - it's my first time contributing code to this repo. Thanks <3!