<pre class="notranslate">What does 'go version' print?
go version devel +26aa53304a48 Fri Mar 07 16:08:12 2014 -0500 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

package main
// #cgo pkg-config: cairo
// #include &lt;cairo/cairo.h&gt;
import "C"
//export test
func test(x *C.cairo_t) {}
func main() {}

What happened?
COMPILER OUTPUT
    # command-line-arguments
    Go type not supported in export: [0]byte
    Go type not supported in export: [0]byte
...CGO1.GO FILE
    func test(x *[0]byte,)  {}
_CGO_EXPORT.H FILE
    extern void test(int* p0);

What should have happened instead?
COMPILER OUTPUT
    [successful build]
...CGO1.GO FILE
    func test(x *_Ctype_cairo_t,)  {}
_CGO_EXPORT.H FILE
    extern void test(cairo_t* p0);

Please provide any additional information below.
In this case, cairo/cairo.h defines cairo_t as
    typedef struct _cairo cairo_t;
but _cairo is never explicitly defined, which is possibly what is confusing cgo.</pre>
<pre class="notranslate">Calling with reflection with embedded types seems to be broken.

Here is a short snippet showing the issue:

    package main
    import "reflect"
    type A struct{}
    type B struct{A}
    func (a *A) S() { println("Hi!") }
    func main() {
        b := &amp;B{}
        b.S()
        reflect.NewValue(b).Method(0).Call([]reflect.Value{})
    }

b.S() works, but the next line fails with:

    panic: type mismatch: *main.A != *main.B

Looking at the source of Call():

    if v := fv.first; v != nil {
        // Hard-wired first argument.
        if fv.isInterface {
            // v is a single uninterpreted word
            memmove(addr(ptr), v.getAddr(), ptrSize)
            off = ptrSize
        } else {
            // v is a real value
            tv := v.Type()
            typesMustMatch(t.In(0), tv)
            n := tv.Size()
            memmove(addr(ptr), v.getAddr(), n)
            off = n
            delta = 1
        }
    }

It looks to my untrained eye like the type checking might be relaxed in the second case
too, in the same way that was done with interfaces in the first case.

The only possible way to reach this code path is via the Method() function, which I
believe is already a proof that the type is indeed acceptable as the receiver of the
given call.

Am I missing something, or could this check be removed?</pre>