Skip to content
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: go list -e does not assign missing import errors to correct package #26909

Open
rsc opened this issue Aug 10, 2018 · 4 comments
Open

cmd/go: go list -e does not assign missing import errors to correct package #26909

rsc opened this issue Aug 10, 2018 · 4 comments

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Aug 10, 2018

See TODO in testdata/script/mod_lists_bad_import.txt.

@rsc

This comment has been minimized.

Copy link
Contributor Author

@rsc rsc commented Aug 17, 2018

It's complicated. The current behavior might even be almost correct. Leaving for Go 1.12.

@rsc rsc modified the milestones: Go1.11, Go1.12 Aug 17, 2018
@rsc rsc added NeedsDecision and removed NeedsFix labels Aug 17, 2018
@bcmills bcmills added the GoCommand label Nov 14, 2018
@rsc rsc modified the milestones: Go1.12, Go1.13 Nov 20, 2018
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Feb 4, 2020

@bcmills, @matloob, and I discussed this last week in the context of #36188. There's currently some ambiguity about whether import errors should be attached to the importing package or the imported package in go list -e -json output.

Here's what we came up with:

  • If the package being imported cannot be built, for example, because it doesn't exist or has no .go files, the error should be attached to the imported package. The error may still have a position in a file in the importing package. If multiple packages import an unbuildable package with the same path, multiple packages with errors should be listed.
  • If the package can be built but the importing package is not allowed to import it, for example because it's an internal package, a main package, or has a different canonical path, the error should be attached to the importing package, and the imported package should be listed normally without error. If the importing package has multiple import errors, we'll only include the first one in go list -e -json output.
@jayconrod jayconrod modified the milestones: Backlog, Go1.15 Feb 4, 2020
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Feb 13, 2020

If the package being imported cannot be built, … the error may still have a position in a file in the importing package. If multiple packages import an unbuildable package with the same path, multiple packages with errors should be listed.

I don't think that's quite right: if the error for a given package is not dependent on the importer, the Error field of the go list -e -json entry for that package should not itself include information about importers. (However, the information in the DepsErrors field of each of those importers should populate the Pos field with the position of the corresponding import line.)

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Feb 13, 2020

If the package can be built but the importing package is not allowed to import it, … the error should be attached to the importing package, and the imported package should be listed normally without error.

The details of this part are a bit subtle. I think in that case the error should be encoded in the Error field for the importing package (rather than the DepsErrors field), because the error did not strictly occur in the course of “loading” the dependency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.