New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
go list
API
go list
APIgo list
API
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>
Are we going to do anything here for 1.17? Thanks. |
It looks like this will be the easiest route to fixing #45827, so this may yet happen for 1.17. |
Change https://golang.org/cl/317409 mentions this issue: |
Change https://golang.org/cl/317299 mentions this issue: |
When CL 241577 lands, 'go list -e' will include unparseable files (like a file without a package declaration) in GoFiles in addition to InvalidGoFiles. This makes go/packages more tolerant of empty test files. With CL 241577, if a file=src.go query is given when an empty _test.go is present, packages.Load will return two matching packages: the library under test, and the internal test package. This CL broadens overlay_test.go so the new behavior doesn't break the test. For golang/go#39986 Change-Id: I14d019129465e928a3f60a2230edd2e2d1d74687 Reviewed-on: https://go-review.googlesource.com/c/tools/+/317409 Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
For #45827 For #39986 Updates #45999 Change-Id: I0c919b6a2e56e7003b90425487eafe0f0eadc609 Reviewed-on: https://go-review.googlesource.com/c/go/+/317299 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Change https://golang.org/cl/317300 mentions this issue: |
go/build.ImportDir returns a *build.Package with various lists of files. If a file is invalid for some reason, for example, because it has a different package name than other files, it's added to InvalidGoFiles in addition to GoFiles, TestGoFiles, or other lists. Previously, files with parse errors or build constraint errors were not included in these lists, which causes problems for tools that use 'go list' since InvalidGoFiles is not printed. With this change, files with any kind of error are added to one of the GoFiles lists. Fixes #39986 Change-Id: Iee007b5092293eb4420c8a39ce731805fe32135f Reviewed-on: https://go-review.googlesource.com/c/go/+/241577 Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
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: