cmd/go: expose InvalidGoFiles as part of `go list` API #39986
Comments
Change https://golang.org/cl/240098 mentions this issue: |
I think we could do this. |
Change https://golang.org/cl/241577 mentions this issue: |
This test exposes a lot of fundamental issues with `go list` overlays. Now that we have the regression test framework, we can copy it over and make any flakes completely reproducible by waiting for each change to complete. The issue here ended up being that initial workspace load returns workspace packages with no associated files due to golang/go#39986. Working around this allows invalidation to proceed as usual. In the process of debugging this, I also noticed that packages can get loaded as command-line-arguments even when we can get the correct package path for them. It's pretty complicated to fix this, so restructured the code a tiny bit and left a TODO. I'd like to come back to this at some point, but it's not pressing since I was able to fix this bug. Fixes golang/go#39646. Updates golang/go#39986. Change-Id: Id6b08a5e92d28eddc731feb0ef3fd3b3fc69e64b Reviewed-on: https://go-review.googlesource.com/c/tools/+/240098 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
We've encountered some limitations with these CLs - specifically with this corner case:
As an alternative, we proposed exposing the InvalidFiles list from go/build as part of the /cc @matloob |
Change https://golang.org/cl/244028 mentions this issue: |
In the case of an invalid package name (the package name is a keyword), `go list` doesn't report any filenames associated with the package. As we have done previously, we can parse these out of the error message. However, it seems like, in this case, the filename is in the error string itself, not the error position. Updates golang/go#39986 Updates golang/go#39763 Change-Id: Id9c68a93ac4f545e4e2152540ca85b92f1df4640 Reviewed-on: https://go-review.googlesource.com/c/tools/+/244028 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
Repro steps
Consider a directory structure like the following:
If
inner.go
andmain.go
are both empty files,go list
returns the following:To extract the Go files associated with these packages, go/packages will have to parse the error messages.
Is there any possibility of listing the empty files in the GoFiles field?
/cc @jayconrod @bcmills @matloob
The text was updated successfully, but these errors were encountered: