Comment 1:

Labels changed: added repo-main, release-go1.4.

Comment 2:

This is really cool. Simpler reproduction case:
cd $GOROOT/src/cmd/api
go run run.go # everything is fine
touch $GOROOT/src/crypto/cipher/asm_amd64.s
go run run.go # magical error from go/types
2014/09/15 11:20:08 error typechecking package crypto/x509:
/Users/rsc/g/go/src/crypto/x509/pem_decrypt.go:49:14: cannot use des.NewCipher (value of
type func(key []byte) (cipher.Block, error)) as func(key []byte) (cipher.Block, error)
value in struct literal (windows-amd64)
It seems like this has to be a bug in go/types. Somehow it is seeing two different
'cipher' packages, but I can't see how.

Owner changed to @griesemer.

Status changed to Accepted.

Comment 3:

The error disappears if the goapi pkgCache is disabled: comment out goapi.go:586 .
I'd say this is a bug in the package cache or how its contents are used with go/types
(rather than go/types itself). Still investigating.

Comment 4:

Looks like amd64 is missing from AllTags coming back from go/build for crypto when you
create that file. Will look at AllTags.

Comment 5:

Observations so far:
1) The bug is reproducible when considering only
    {GOOS: "darwin", GOARCH: "386"},
    {GOOS: "windows", GOARCH: "amd64"},
as (goapi.go) contexts entries.
2) The pkgCache contents are different depending on whether the asm_amd64.s file is
present or not: If the file is present, the pkgCache contains the keys (among others):
    $GOROOT/src/crypto/cipher
    $GOROOT/src/crypto/cipher,amd64
(otherwise it's just:
    $GOROOT/src/crypto/cipher
)
3) The presence of the assembly file affects the go/build.Package.AllTags list; if the
file is present, the list contains the additional tag "amd64" for the cipher package.
4) This tag list is used to create the respective pkgCache keys (see 2).
For reasons I don't fully understand yet, the type-checker must be using entries from
the $GOROOT/src/crypto/cipher and $GOROOT/src/crypto/cipher,amd64 package at the same
time - while the two packages are identical, the package pointers are not, resulting in
an error.
Possible explanations:
- the goapi.go code assumes that the type-checker can handle packages that are
isomorphic but have different package objects (that's not the case)
- there's a bug in how goapi.go sets up the pkgCache.

Comment 6:

The pkgCache code is clearly not quite right. If we ever hit this in real code in the
repo, we can pull out the pkgCache. But right now it's cutting 40% of the runtime for
the api check, so I'd like to keep it.
I have not checked, but I think maybe this would go away if there were build tags
present for all possible architectures instead of amd64. The all possible thing is much
more common: you have one file for amd64, one for 386, one for arm. Maybe there's
overlap but you basically never have one for amd64 and nothing for 386/arm, or else
you'd have an incomplete package on those. That can happen in external code maybe but
not in the standard library. Because of that theory, it is possible that we will never
see this in a real standard library package.

Status changed to Unfortunate.

See #21181 for the cause of this issue.