Go: x/cmd/gotype: Now considers C.int an invalid type

[jmunson]

It appears that in go1.9, gotypes now handles C.int differently than it did in previous versions, now producing an invalid type error.

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

go version go1.9 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

arch linux amd64

What did you do?

❯go get github.com/mattn/go-sqlite3
❯ gotype ~/go/src/github.com/mattn/go-sqlite3/

What did you expect to see?

No type errors, as was the case with go1.8.3

What did you see instead?

/home/jmunson/go/src/github.com/mattn/go-sqlite3/error.go:14:17: invalid constant type invalid type

[ianlancetaylor]

CC @griesemer

[griesemer]

Before I dive into this, could you please check and let me know if there's a difference when you run gotype with the -c=gc option? (This was the default in the past, now it's -c=source.) Thanks.

[mjtrangoni]

@griesemer I have the same problems with go1.9.1
$ gotype -c=source vendor/github.com/mattn/go-sqlite3/error.go vendor/github.com/mattn/go-sqlite3/error.go:16:17: invalid constant type invalid type vendor/github.com/mattn/go-sqlite3/error.go:80:9: undeclared name: errorString $ gotype -c=gc vendor/github.com/mattn/go-sqlite3/error.go vendor/github.com/mattn/go-sqlite3/error.go:16:17: invalid constant type invalid type vendor/github.com/mattn/go-sqlite3/error.go:80:9: undeclared name: errorString

[JC1738]

See the same issue with github.com/mattn/go-sqlite3 on

go version go1.9.2 linux/amd64

[ysqi]

go build is ok, get error under go generate :

stringer: checking package: database.go:31:2: could not import MYProject/db 
(type-checking package "****/db" failed 
(***db.go:16:4: could not import github.com/mattn/go-sqlite3 (type-checking package "***/vendor/github.com/mattn/go-sqlite3" failed 
(/***/vendor/github.com/mattn/go-sqlite3/error.go:14:17: invalid constant type invalid type))))
***/net.go:825: running "stringer": exit status 1

[aletheia7]

gotype o.go produces

o.go:50:11: invalid constant type Login

for this code:

type Login C.odbUSHORT                                                                                                                                                                                               

const (                                                                                                                                                                                                              
    Normal   Login = C.ODB_LOGIN_NORMAL                                                                                                                                                                              
    Reserved       = C.ODB_LOGIN_RESERVED                                                                                                                                                                            
    Single         = C.ODB_LOGIN_SINGLE                                                                                                                                                                              
) 

These constants compile fine.

gotype is used by stringer. stringer fails to parse constants because of gotype.

[griesemer]

Simple reproducer for the issues with github.com/mattn/go-sqlite3:

package p

import "C"
import "unsafe"

const _ C.int = 0xff

type T struct {
    Name    string
    Ordinal int
}

func f(args []T) {
    var s string
    for i, v := range args {
        cname := C.CString(v.Name)
        args[i].Ordinal = int(C.sqlite3_bind_parameter_index(s, cname))
        C.free(unsafe.Pointer(cname))
    }
}

gotype reports:

x.go:8:9: invalid constant type invalid type
x.go:17:6: i declared but not used

At least the first error is trivial to fix (CL forthcoming).

[gopherbot]

Change https://golang.org/cl/88375 mentions this issue: go/types: more robust behavior in the presence errors (cause by C objects)

[griesemer]

Changed milestone to Go1.10 per discussion with @ianlancetaylor .