cmd/cgo: mysterious missing typedef[...] definition on Mac OS X handling internal Objective-C types

[andlabs]

from src/cmd/cgo/gcc.go:
  1286              if isStructUnionClass(sub.Go) {
  1287                  // Use the typedef name for C code.
  1288                  typedef[sub.Go.(*ast.Ident).Name].C = t.C
  1289              }

When handling one of Objective-C's internal types, go get github.com/andlabs/ui fails
with a nil pointer dereference panic at line 1288 above. Upon further investigation:

### sub.Go:&ast.Ident{NamePos:0, Name:"_Ctype_struct_objc_object",
Obj:(*ast.Object)(nil)} sub.Go.(*ast.Ident):&ast.Ident{NamePos:0,
Name:"_Ctype_struct_objc_object", Obj:(*ast.Object)(nil)}
....Name:"_Ctype_struct_objc_object"
typedef:map[string]*main.Type{"_Ctype_struct_objc_cache":(*main.Type)(0x2083eacc0),
"_Ctype_int":(*main.Type)(0x2084d7480),
"_Ctype_struct_objc_method_list":(*main.Type)(0x2084d7e00),
"_Ctype_SEL":(*main.Type)(0x2084d7b00),
"_Ctype_Class":(*main.Type)(0x2084d7040),
"_Ctype_long":(*main.Type)(0x2084d7280),
"_Ctype_struct_objc_ivar":(*main.Type)(0x2084d7700),
"_Ctype_Method":(*main.Type)(0x2083eac00),
"_Ctype_struct_objc_selector":(*main.Type)(0x2084d7a80),
"_Ctype_IMP":(*main.Type)(0x2084d7cc0),
"_Ctype_struct_objc_method":(*main.Type)(0x2084d7d80),
"_Ctype_uint":(*main.Type)(0x2084d7f80),
"_Ctype_Protocol":(*main.Type)(0x2083eb000),
"_Ctype_char":(*main.Type)(0x2084d71c0),
"_Ctype_struct_objc_ivar_list":(*main.Type)(0x2084d7780)}
t:&main.Type{Size:8, Align:-1, C:(*main.TypeRepr)(0x2084f66f0),
Go:(*ast.Ident)(0x2084e53c0), EnumValues:map[string]int64(nil), Typedef:""}
t.C:&main.TypeRepr{Repr:"Protocol", FormatArgs:[]interface {}(nil)}
### expr:(*main.Type)(nil)

so while all the parts of the typedef[...] line are valid, the typedef[...] expression
itself is not. I'm not sure what's going on here.

I'm running Mac OS X 10.8 with go version
    go version devel +f39dff1bf0d4 Thu Jun 19 22:18:24 2014 +1000 darwin/amd64
and clang version
    Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
    Target: x86_64-apple-darwin12.5.0
    Thread model: posix
but people at andlabs/ui#9 have different setups.

Thanks!

[ianlancetaylor]

Comment 1:

I think we must be setting the typedef without seeing the struct to which it is
typedef'ed.
Try changing that line to do nothing if there is no entry in the typedef map and see
what happens.

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

[ianlancetaylor]

Comment 2:

I haven't been able to reproduce this on GNU/Linux.  Can you try to reduce this to a
small standalone test case?  It would be even better if the test case could be in C.

[andlabs]

Comment 3:

jrick (the conformal/gotk3 guy) seems to think this is a clang-specific problem. (I
wouldn't be surprised...)
[11:30] <jrick> andlabs: I think issue #8238 is related to clang, when I build go
1.3 with gcc, cgo doesn't panic (but I get other weirdness with *C.T and *C.struct__T
errors)
[11:32] <jrick> what's even more odd is that the *C.struct__T errors don't seem
deterministic
[11:32] <jrick> i.e. run go get once, and the build fails
[11:33] <jrick> run it again, and everything works :/
[11:33] <jrick> I wonder if my glib/gtk packages are built with clang
That being said, I can try both comments's requests on OS X later (and then remember how
to use GNUstep for a Linux-based example).

[andlabs]

Comment 4:

"Try changing that line to do nothing if there is no entry in the typedef map and see
what happens."
No panic; everything seems to compile and run fine.
Minimal test:
    package main
    // #cgo LDFLAGS: -framework Foundation -lobjc
    // #include <objc/message.h>
    // #include <objc/objc.h>
    // #include <objc/runtime.h>
    import "C"
    func main() { var x C.id; println(x) }
Can't reproduce on Linux; compilation works fine but fails during link due to
incompatible linker options in the LDFLAGS above.
    pietro@pietro-laptop:/tmp$ gcc --version
    gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
    Copyright (C) 2013 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    pietro@pietro-laptop:/tmp$ clang --version
    Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
    Target: x86_64-pc-linux-gnu
    Thread model: posix

[mdempsky]

Comment 5:

FYI, we just committed revision 0015a25415455c390ae135bef7de2d5e2b10ee88 to fix issue
8368, which was another nil pointer dereference at gcc.go:1288.  It would be interesting
to know if you're still able to reproduce this issue at tip.

[gopherbot]

Comment 6 by joshrickmar:

I've been able to build gotk3 using a clang-built go tip several times now with no
panics or other issues (that also includes the missing typedef issues from issue #8463).

[ianlancetaylor]

Comment 7:

Sounds like this was fixed--please reopen if not.

Status changed to Duplicate.

Merged into issue #8368.

[rsc]

Comment 8:

Labels changed: added release-none, removed release-go1.3.1.