go/types: go vet reporting incorrect "imported but not used" error

[somersf]

What version of Go are you using (go version)?

This issue appeared in a canary build/test of part of our Go codebase, using go master HEAD recently.

Does this issue reproduce with the latest release?

This issue is not present in the released go1.10 or go1.9.4 versions.

This regression seems to have appeared in HEAD shortly after go1.11 development opened.

What operating system and processor architecture are you using (go env)?

GOOS="linux" GOARCH="amd64"
GOOS="darwin" GOARCH="amd64"

What did you do?

Create a package issue containing two seperate files:

a.go:

package issue

import "regexp"

type Y interface {
	X

	Expr() *regexp.Regexp
}

b.go:

package issue

import "regexp"

type X interface {
	Exprs() []*regexp.Regexp
}

To reproduce, use a go HEAD version after approximately Feb 13th, and run:

$ cd issue

$ go vet .
# _/home/user/go-project/issue
./b.go:3:8: "regexp" imported but not used
vet: typecheck failures

Changing the order the files are presented to go vet changes the behavior:

$ cd issue

$ go vet a.go b.go
# command-line-arguments
./b.go:3:8: "regexp" imported but not used
vet: typecheck failures

$ go vet b.go a.go             # <--- This order succeeds
$ echo $?
0

Additional Information

From our testing logs:
go version devel +ce5fa6d5e9 Tue Feb 13 16:00:30 2018 +0000 linux/amd64 has this regression.
go version devel +c52e27e68d Sun Feb 11 20:41:48 2018 +0000 linux/amd64 succeeds.

A git bisect run, checking between HEAD (+7a1347a1a1 on 2018-02-18) and +c52e27e68d indicates that the regression may have been introduced or uncovered as part of commit dd44895 (merged to master Feb 12th).

What did you expect to see?

go vet should succeed on these input files, regardless of the file input order.

What did you see instead?

go vet is erroneously reporting "regexp" imported but not used when the package is being used for a return type.

The behavior also appears to be sensitive to the order in which go vet processes the input files.

[rmmh]

Here's a repro program that bisects to the same commit and demonstrates the order dependence, minimized from Prometheus.

package main

import (
        "fmt"
        "go/ast"
        "go/importer"
        "go/parser"
        "go/token"
        "go/types"
        "log"
)

// passes if analyzed this direction.
var srcs = []string{`
package a
import "io"
type Metric interface {
        Write(*io.Writer) error
}`, `
package a
type Untyped interface {
        Metric
}
`, `
package a
type value struct {
        selfCollector
}`, `
package a
type Collector interface {
}
type selfCollector struct {
        self Metric
}
func (c *selfCollector) init(self Metric) {
        c.self = self
}`}

func typecheck() {
        fset := token.NewFileSet()
        conf := types.Config{
                Importer: importer.For("source", nil),
                Error:    func(err error) { log.Println(err) },
        }
        files := []*ast.File{}
        for i, src := range srcs {
                parsed, err := parser.ParseFile(fset, fmt.Sprintf("f%d.go", i), src, 0)
                if err != nil {
                        log.Fatal(err)
                }
                files = append(files, parsed)
        }
        _, err := conf.Check(".", fset, files, nil)
        if err != nil {
                fmt.Println("bad typecheck!")
        }
}

func main() {
        typecheck()
        fmt.Println("first check succeeded")
        srcs[0], srcs[1], srcs[2] = srcs[1], srcs[2], srcs[0]
        typecheck()
}

[griesemer]

Confirmed. I will look into this shortly; this is clearly a newly introduced issue. Thanks for reporting with concise reproducer.

[griesemer]

The problem is worse. For a.go:

package bug
import "go/ast"
type A interface { B }

and b.go:

package bug
import "go/ast"
type B interface { b() ast.Node }

we get the error

b.go:2:8: "go/ast" imported but not used

in b.go which uses go/ast but not in a.go which doesn't use it.

The problem is that the method set of A is computed by including the methods from B which then all are type-checked while in the file scope of A; hence it appears that go/ast is used by A (while checking the b method). But since the b method is already type-checked, it doesn't need to be checked again in B, leading to the lack of use of go/ast in b.go`.

[griesemer]

In fact, for b.go:

package bug
type B interface { b() ast.Node }

the code type-checks w/o errors...

[gopherbot]

Change https://golang.org/cl/96375 mentions this issue: go/types: add -panic flag to gotype command for debugging

[gopherbot]

Change https://golang.org/cl/96376 mentions this issue: go/types: type-check embedded methods in correct scope (regression)