cmd/go: print import stack when reporting error constructing build list

[jayconrod]

In module mode, every build starts by constructing the build list, the set of modules at specific versions that will be involved in the build. We construct the build list by exploring the import graph rooted at the command line arguments, adding modules to satisfy any imports that can't be resolved.

There are a number of things that can go wrong during this process, not all of which are under the user's direct control. For example, suppose a transitive dependency requires github.com/golang/lint, but the go.mod in that repository declares the module path golang.org/x/lint. The package importing github.com/golang/lint is wrong, but we don't currently report what that package is or why it's part of the build.

When an error like this occurs, we should report the chain of imports from the command line arguments to the problematic package.

[gopherbot]

Change https://golang.org/cl/166984 mentions this issue: cmd/go: print require chains in build list errors

[thepudds]

@jayconrod I had this question when ran this for the first time.

If you see an error like this:

go get: github.com/Sirupsen/logrus@v1.0.3 ->
        github.com/Sirupsen/logrus@v1.4.1: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

First, does the first transition there represent an upgrade? If so, I didn't understand that at first, and at first I thought that -> represented a dependency given that is what it means later in bigger errors. If that does represent an upgrade, maybe it could help to do something like replacing the -> with upgraded to, or some other English phrase?

Second, I think the main module is implied? If so, maybe the "get" could be eliminated and add in the main module as the first line?

I don't think this is quite perfect, but maybe something like:

go:  github.com/my/module ->
     github.com/Sirupsen/logrus@v1.0.3: upgraded to
     github.com/Sirupsen/logrus@v1.4.1: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

CC @mfridman

[jayconrod]

@thepudds "upgraded to" is probably the right phrasing. @heschik also asked me about this today, too. I'll change it.

go get: is a prefix of all the error messages for that command, so I think that should be left alone.

About the main module, unfortunately, that's a difficult change to make because we don't know whether requirements are direct or transitive when that error comes up. go get -u constructs the regular build list, adds any named arguments with specific versions, then constructs a new build list from that list where we also upgrade everything. Most of these error come up in that second list, but we've already thrown away the original module graph at that point, so we can't trace a path from the main module to a transitive requirement. All transitive requirements look like direct requirements.

We should refactor this. It will be a complicated change though.

[gopherbot]

Change https://golang.org/cl/171150 mentions this issue: cmd/go: describe dependencies in build list error messages