Comment 1:

I think I might've fixed this in the process of fixing 2906

Owner changed to @bradfitz.

Status changed to Started.

Comment 2:

Actually, why does this matter?
goapi isn't supposed to be a completely generic tool (at least not yet).  It's only
supposed to analyze the Go 1 codebase.
If it runs against the Go 1 codebase with correct results, that's good enough for now.
Once the AST has type information, then this tool gets less hacky.

Status changed to WaitingForReply.

Comment 3:

It was a sub-isssue of 2906, I actually only found this on unexported constants so it's
a non-problem. I still have problems when running the tool on gccgo codebase (is it a
target for Go1?):
on os package:
unknown kind in const "WNOHANG" (*ast.SelectorExpr): unknown constant reference to
syscall.WNOHANG
on syscall package:
unknown type of variable "SizeofCmsghdr", type *ast.CallExpr, error = unresolved named
"int"
code: int(unsafe.Sizeof(Cmsghdr{}))
(here gccgo has var SizeofCmsgHdr instead of const SizeofMsgHdr, I guess that goes under
issue #1790).

Comment 4:

syscall.WNOHANG is defined in the generated file sysinfo.go.  Does goapi see that file
when you run it?  (I have not tried running goapi on the gccgo library.)
We could rewrite SizeofCmsgHdr and friends to be
    var SizeofCmsgHdr int = unsafe.Sizeof(Cmsghdr{})
but it would be even nicer if we could figure out a way to make them const as they are
for 6g.  I suppose we could change -fdump-go-spec to dump the size of every struct.

Comment 5:

Don't dirty up gccgo for my goapi's sake.  I'll make sure it works there.

Comment 6:

Labels changed: added priority-go1, go1-must, removed priority-triage.

Status changed to Accepted.

Comment 7:

I tried to reproduce this and failed. Can you construct a complete example as part of
p1.go and p2.go (the testdata for the command)?

Comment 8:

The original issue is supposed to have been fixed by
http://golang.org/cl/5644050, I believe.

Comment 9:

Does cmd/api work with gccgo's tree?  We should repurpose this bug for that, or close
this and open an "audit gccgo vs. gc" bug.

Comment 10:

Opened https://golang.org/issue/3156
Closing this one.

Comment 11:

Status changed to Fixed.