-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/go/packages: all "no Go files in" errors get assigned to single package as a single error #32755
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
Comments
The The underlying
though the extra output on stderr is noteworthy. |
Worse yet, if we attempt to load a healthy package in addition to |
I'm reasonably sure that this is caused by this special case in the golist driver. This might be a bug on the older go1.1 version which I assume is supported (?) but doesn't seem to be an issue on my version (go1.12.6). Either way, I think the correct way to correct this is to add special JSON nodes to |
Adds some hacks to work around go list bugs causing golang/go#31462 and golang/go#32755. In addition, appends error messages generated in this manner to stdout instead of discarding stdout entirely, and ensures that this does not cause a conflicting package error by adding an internal field to packageJson.
Change https://golang.org/cl/185077 mentions this issue: |
Adds some hacks to work around go list bugs causing golang/go#31462 and golang/go#32755. In addition, appends error messages generated in this manner to stdout instead of discarding stdout entirely, and ensures that this does not cause a conflicting package error by adding an internal field to packageJson.
Adds some hacks to work around go list bugs causing golang/go#31462 and golang/go#32755. In addition, appends error messages generated in this manner to stdout instead of discarding stdout entirely, and ensures that this does not cause a conflicting package error by adding an internal field to packageJson.
Adds some hacks to work around go list bugs causing golang/go#31462 and golang/go#32755. In addition, appends error messages generated in this manner to stdout instead of discarding stdout entirely, and ensures that this does not cause a conflicting package error by adding an internal field to packageJson.
Adds some hacks to work around go list bugs causing golang/go#31462 and golang/go#32755. In addition, appends error messages generated in this manner to stdout instead of discarding stdout entirely, and ensures that this does not cause a conflicting package error by adding an internal field to packageJson.
Adds some hacks to work around go list bugs causing golang/go#31462 and golang/go#32755. In addition, appends error messages generated in this manner to stdout instead of discarding stdout entirely, and ensures that this does not cause a conflicting package error by adding an internal field to packageJson.
Adds some hacks to work around go list bugs causing golang/go#31462 and golang/go#32755. In addition, appends error messages generated in this manner to stdout instead of discarding stdout entirely, and ensures that this does not cause a conflicting package error by adding an internal field to packageJson.
This seems to have been fixed on head. Please reopen if not. Running with the same gopath layout on Go 1.13 with GO111MODULE=off, and the following test code:
produces the following output for me:
|
What version of Go are you using (
go version
)?What did you do?
https://play.golang.org/p/Y0ANYGkISpa
What did you expect to see?
Two packages, sandbox/empty1 and sandbox/empty2, each with one error
What did you see instead?
One package, sandbox/empty2, with one error but whose error message contains two errors for two separate packages.
/cc @matloob
The text was updated successfully, but these errors were encountered: