cmd/go: 'go get -d' does not report line numbers in errors for bad import statements

[bcmills]

The fix for #41315 has revealed another variant of issue #34393.

Adding the following test case to mod_build_info_err.txt

+go get -d ./main
+stderr 'bad[/\\]bad.go:3:8: malformed module path "🐧.example.com/string": invalid char ''🐧'''

gives the failure mode of #41315 at release-branch.go1.15. At head, it gives a different, but still not quite right, failure mode:

+ go test cmd/go '-run=TestScript/^mod_build_info_err$'
go test proxy running at GOPROXY=http://127.0.0.1:44957/mod
--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/mod_build_info_err (0.05s)
        script_test.go:211:
            # This test verifies that line numbers are included in module import errors.
            # Verifies golang.org/issue/34393. (0.036s)
            > go list -e -deps -f '{{with .Error}}{{.Pos}}: {{.Err}}{{end}}' ./main
            [stdout]
            bad/bad.go:3:8: malformed import path "🐧.example.com/string": invalid char '🐧'
            > stdout 'bad[/\\]bad.go:3:8: malformed import path "🐧.example.com/string": invalid char ''🐧'''
            > go get -d ./main
            [stderr]
            m/main imports
                m/bad imports
                🐧.example.com/string: import missing
            [exit status 1]
            FAIL: testdata/script/mod_build_info_err.txt:7: unexpected command failure

FAIL

Notably, the import stack for this error message is again bereft of line numbers (as in #34393).

CC @jayconrod @matloob @rogpeppe

[gopherbot]

Change https://golang.org/cl/258219 mentions this issue: cmd/go: test more commands in mod_build_info_error

[bcmills]

I think this needs to be a blocker for 1.16: with -mod=readonly we're going to end up encouraging wider use of go get.

[bcmills]

(The import missing error message in the above trace is a separate bug in go get, which I plan to fix as part of #37438.)

[toothrot]

@bcmills What else is left to do on this before the release?

[cagedmantis]

@bcmills Is there anything left to do on this before the release?

[bcmills]

I'm not sure. I'm still in the process of overhauling the go get implementation for #36460.

[bcmills]

We should decide whether this is feasible to fix for the release, but if it turns out to be too invasive we can punt it to 1.17.

[jayconrod]

Looked into this a bit. In go get, we invoke modload.LoadPackages with AllowErrors = true and SilenceErrors = false. This means the stacks are currently formatted by modload.loadPkg.stackText. I see two solutions:

1. modload.loadPkg doesn't currently track locations of import declarations. We could modify imports.ScanDir to return that information.
2. We could use load.PackagesAndErrors instead. That would give us error messages identical to those printed by go build, but it would apply build constraints, which we probably don't want.

I think it's viable to implement (1) before 1.16, but there are a lot of open release blockers that should fix first. This shouldn't actually block the release, and it's probably too big to go in after the RC.