Open
Description
What version of Go are you using (go version
)?
$ go version $ go version go version go1.13.5 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/hajimehoshi/Library/Caches/go-build" GOENV="/Users/hajimehoshi/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/hajimehoshi/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ht/ky_bwgzs4bd5z1hh02k34x_h0000gn/T/go-build430597543=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
Created these files in one directory.
go.mod
:
module example.com/m
go 1.13
require golang.org/x/tools v0.0.0-20200114052453-d31a08c2edf2 // indirect
main.go
:
// +build ignore
package main
import (
"fmt"
"os"
"golang.org/x/tools/go/packages"
)
func main() {
cfg := &packages.Config{
Mode: packages.NeedName | packages.NeedFiles |
packages.NeedImports | packages.NeedDeps |
packages.NeedTypes | packages.NeedSyntax | packages.NeedTypesInfo,
Env: append(os.Environ(), "GOOS=android", "CGO_ENABLED=1"),
}
allPkg, err := packages.Load(cfg, ".")
if err != nil {
panic(err)
}
for _, pkg := range allPkg {
if len(pkg.Errors) > 0 {
panic(fmt.Sprintf("%v", pkg.Errors))
}
}
}
c.go
:
package lib
import "C"
What did you expect to see?
No error
What did you see instead?
$ gl clean -cache && go run main.go
panic: [/Users/hajimehoshi/test/cgo/c.go:3:8: could not import C (no metadata for C)]
goroutine 1 [running]:
main.main()
/Users/hajimehoshi/test/cgo/main.go:24 +0x2c6
exit status 2
This is similar to #36441
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Activity
hajimehoshi commentedon Jan 14, 2020
CC @matloob
[-]x/tools/go/packages: Load returned error when specifying GOOS[/-][+]x/tools/go/packages: Load returned packages with errors when specifying GOOS[/+]hyangah commentedon Jan 14, 2020
If GOOS is not specified, does it work? I wonder if this is the same issue as #36441.
hajimehoshi commentedon Jan 14, 2020
Hmm, I thought yes, but it looks like this depends on the cache state. Let me double check.
hajimehoshi commentedon Jan 14, 2020
Oops, now I found this issue even without GOOS. Then this is the same as #36441.
hajimehoshi commentedon Jan 14, 2020
Removing
packages.ModeTypes
was necessary to reproduce the issue.[-]x/tools/go/packages: Load returned packages with errors when specifying GOOS[/-][+]x/tools/go/packages: Load returned packages with errors when specifying ModeTypes[/+]hajimehoshi commentedon Jan 14, 2020
Updated the first comment, but I'm fine to close this marking 'duplicated'.
[-]x/tools/go/packages: Load returned packages with errors when specifying ModeTypes[/-][+]x/tools/go/packages: Load returned packages with errors when specifying GOOS[/+]hajimehoshi commentedon Jan 14, 2020
Now I realized I omitted packages.Need*, and this was wrong. I updated the issue again. Sorry for the confusion.
Then yes it worked without GOOS. This can be reproduced when specifying various packages.Mode* values. This sounds a different issue from #36441.
hajimehoshi commentedon Jan 15, 2020
I'm taking a look at this.
gopherbot commentedon Jan 15, 2020
Change https://golang.org/cl/214738 mentions this issue:
go/packages: ignore importing C
11 remaining items
hyangah commentedon Jan 17, 2020
@matloob I don't know much about
go/packages
but, philosophically, given that some analysis tools and analysis libraries can operate on even broken source code, I wonder why we need to enforce this strict restriction on cgo. What is the potential concern if we skip or ignore the cgo related errors? Will it cause the gobind or similar tools to generate incorrect binding code?Is there any option to skip cgo but still analyze the go part?
matloob commentedon Jan 17, 2020
It's okay to ignore errors. go/packages already tries to do the best it can, and if the information that gomobile needs doesn't depend on perfect code then it should work fine as is.
Specifically for this bug, what I meant was that if we can't depend on Load returning a package if cgo can't run. That's what this bug was originally filed for. But that doesn't mean that tools can't work on the results of go/packagse.
gopherbot commentedon Jan 21, 2020
Change https://golang.org/cl/214498 mentions this issue:
cmd/gomobile: enable Cgo
hajimehoshi commentedon Jan 21, 2020
OK I'll adopt the way to just ignore Errors for #27234.
cmd/gomobile: enable Cgo
cmd/gomobile: enable Cgo
cmd/gomobile: enable Cgo
-export -covermode=atomic
is used #68212