x/tools/go/packages: seems to do nothing when given non-Go files

[mvdan]

docker run -i golang:1.12beta2-stretch <<-SCRIPT
        export GO111MODULE=on
        go get golang.org/x/tools/go/packages/[email protected]
        echo "package foo" >f1.go
        echo "package bar" >f2.bar

        echo "f1.go"
        gopackages f1.go; echo $?
        echo "f2.bar"
        gopackages f2.bar; echo $?
        echo "f1.go f2.bar"
        gopackages f1.go f2.bar; echo $?
SCRIPT

Output:

f1.go
Go package "command-line-arguments":
        package foo
        has no exported type info
        file /go/f1.go

0
f2.bar
Go package "f2.bar":
        package
        has no exported type info
        -: unknown import path "f2.bar": cannot find module providing package f2.bar

0
f1.go f2.bar
0

The third case should either error, or give one package. Seems like there should be an error somewhere:

$ go list -e -json f1.go f2.bar
named files must be .go files

Not a huge problem, but it did throw me off. A tool I wrote on top of go/packages does absolutely nothing when given a Go file and some non-Go files after, which puzzled me.

/cc @matloob @ianthehat

[Skarlso]

Hi @mvdan. Can I help? :)

[mvdan]

If you mean picking up the issue, go ahead. It's not assigned.

[Skarlso]

@mvdan Yeah that's what I meant. Thanks! Cool. :)

[Skarlso]

@mvdan HI!

Correct me if I'm wrong, but according to your example this is the scenario that's not working:

gopackages f1.go f2.bar; echo $?

Right? While this is working:

gopackages f2.bar; echo $?

It seems to me that it can read non-go files, but not if they are together with other files?

[mvdan]

Please see the docker instructions in the original post; they contain a complete example, along with what I'd consider two possible expected outcomes. The current outcome definitely seems wrong to me.

I'm not sure that this is a good first issue if you're looking to contribute to go/packages. I think the fix here would be to error just like go list does, but I'm not sure - that's why I pinged Michael and Ian.

[Skarlso]

Oh! Hang on. I misread the whole thing. So sorry.

This is the error:

-: unknown import path "f2.bar": cannot find module providing package f2.bar

For some reason I thought it's expected. While list says it's not a go file. There is a discrepancy in behaviour between the two. Right.

I thought that the fact that there is no output on the third try is the problem.

[Skarlso]

Oh I think I might know what's going on. It seems like it interprets it as a package name and of course it can't find that instead of a file.

[Skarlso]

Hah. I think I located the error. Going to submit a CL soon once I narrowed it down to a unit test. 👍

[Skarlso]

So the problems appears to be that stderr is not checked for errors from go execute.

Go correctly says this in stderr:

stderr:  named files must be .go files

But this is being ignored. I need a nice way of handling this. :)

[Skarlso]

Unfortunately because of #26319 I can't really check stderr for go failing. :/ I have to replicate the Args checker in the Loader... 🤔

[Skarlso]

@mvdan Is this a satisfactory outcome?

❯ ./gopackages f1.go f2.bar
ARGS:  [f1.go f2.bar]
Called with the following patterns:  [f1.go f2.bar]
rest patterns:  [f1.go f2.bar]
gopackages: named files must be .go files: f2.bar

Please ignore the debug data. :)

[gopherbot]

Change https://golang.org/cl/164663 mentions this issue: x/tools/go/packages: seems to do nothing when given non-Go files

[Skarlso]

Found out why the error isn't working. :D

	if len(patterns) > 0 && strings.HasSuffix(patterns[0], ".go") {
		return []*Package{GoFilesPackage(patterns)}
	}

It only checks the first value. Thus, if I change the multiple call to f2.bar f1.go, I'm seeing the proper error. Although proper is a strong word, because the errors will be the same, just for a different name. :D

❯ go list -e -json -- f2.bar f1.go
{
        "ImportPath": "f2.bar",
        "Match": [
                "f2.bar"
        ],
        "Incomplete": true,
        "Error": {
                "ImportStack": [
                        "f2.bar"
                ],
                "Pos": "",
                "Err": "unknown import path \"f2.bar\": cannot find module providing package f2.bar"
        }
}
{
        "ImportPath": "f1.go",
        "Match": [
                "f1.go"
        ],
        "Incomplete": true,
        "Error": {
                "ImportStack": [
                        "f1.go"
                ],
                "Pos": "",
                "Err": "unknown import path \"f1.go\": cannot find module providing package f1.go"
        }
}

Even though f1.go should have worked...

[gopherbot]

Change https://golang.org/cl/166398 mentions this issue: x/tools/go/packages: seems to do nothing when given non-Go files