GitLab

The __uint128_t type appears in darwin/arm header files processed by
cgo -godefs in http://golang.org/cl/16045.

Change-Id: I666194c65dee8ea0ae933d2f02a3abe4581c4697
Reviewed-on: https://go-review.googlesource.com/16046

Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cgo panics in Package.rewriteRef for:

var a = C.enum_test(1)
or
p := new(C.enum_test)

when the corresponding enum type is not defined.

Check nil values for Type fields and issue a proper
error instead.

Fixes #11097
Updates #12160

Change-Id: I5821d29097ef0a36076ec5273125b09846c7d832
Reviewed-on: https://go-review.googlesource.com/15264

Reviewed-by: Ian Lance Taylor <iant@golang.org>

In order to fix issue #9401 the compiler was changed to add a padding
byte to any non-empty Go struct that ends in a zero-sized field.  That
causes the Go version of such a C struct to have a different size than
the C struct, which can considerable confusion.  Change cgo so that it
discards any such zero-sized fields, so that the Go and C structs are
the same size.

This is a change from previous releases, in that it used to be
possible to refer to a zero-sized trailing field (by taking its
address), and with this change it no longer is.  That is unfortunate,
but something has to change.  It seems better to visibly break
programs that do this rather than to silently break programs that rely
on the struct sizes being the same.

Update #9401.
Fixes #11925.

Change-Id: I3fba3f02f11265b3c41d68616f79dedb05b81225
Reviewed-on: https://go-review.googlesource.com/12864

Reviewed-by: Russ Cox <rsc@golang.org>

The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.

I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.

Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048

Reviewed-by: Rob Pike <r@golang.org>

Change-Id: Ifb8e4e13c7778a7c0113190051415e096f5db94f
Reviewed-on: https://go-review.googlesource.com/11390

Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #10453.

Change-Id: I77470279865d4c954df615d6594c69edf68c28ca
Reviewed-on: https://go-review.googlesource.com/9090

Reviewed-by: Ian Lance Taylor <iant@golang.org>

Comment changes only.

Change-Id: I56848814564c4aa0988b451df18bebdfc88d6d94
Reviewed-on: https://go-review.googlesource.com/7721

Reviewed-by: Rob Pike <r@golang.org>

This patch was previously sent for review using hg:
golang.org/cl/173930043

Change-Id: I559a2f2ee07990d0c23d2580381e32f8e23077a5
Reviewed-on: https://go-review.googlesource.com/3033

Reviewed-by: Ian Lance Taylor <iant@golang.org>

While we're here, rename TestIssue7234 to Test7234 for consistency
with other tests.

Fixes #9557.

Change-Id: I22b0a212b31e7b4f199f6a70deb73374beb80f84
Reviewed-on: https://go-review.googlesource.com/2654

Reviewed-by: Ian Lance Taylor <iant@golang.org>

Removing #cgo directive parsing from cmd/cgo was done in
https://golang.org/cl/8610044.

Change-Id: Id1bec58c6ec1f932df0ce0ee84ff253655bb73ff
Reviewed-on: https://go-review.googlesource.com/2501

Reviewed-by: Ian Lance Taylor <iant@golang.org>

Now that there's no 6c compiler anymore, there's no need for cgo to
generate C headers that are compatible with it.

Fixes #9528

Change-Id: I43f53869719eb9a6065f1b39f66f060e604cbee0
Reviewed-on: https://go-review.googlesource.com/2482

Reviewed-by: Ian Lance Taylor <iant@golang.org>

+ Regression test.

Fixes #9026.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/162490043

Partial undo, changes to ldelf.c retained.

Some platforms are still not working even with the integrated assembler disabled, will have to find another solution.

««« original CL description
cmd/cgo: disable clang's integrated assembler

Fixes #8348.

Clang's internal assembler (introduced by default in clang 3.4) understands the .arch directive, but doesn't change the default value of -march. This causes the build to fail when we use BLX (armv5 and above) when clang is compiled for the default armv4t architecture (which appears to be the default on all the distros I've used).

This is probably a clang bug, so work around it for the time being by disabling the integrated assembler when compiling the cgo assembly shim.

This CL also includes a small change to ldelf.c which was required as clang 3.4 and above generate more weird symtab entries.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/156430044
»»»

LGTM=minux
R=iant, minux
CC=golang-codereviews
https://golang.org/cl/162880044

Fixes #8348.

Clang's internal assembler (introduced by default in clang 3.4) understands the .arch directive, but doesn't change the default value of -march. This causes the build to fail when we use BLX (armv5 and above) when clang is compiled for the default armv4t architecture (which appears to be the default on all the distros I've used).

This is probably a clang bug, so work around it for the time being by disabling the integrated assembler when compiling the cgo assembly shim.

This CL also includes a small change to ldelf.c which was required as clang 3.4 and above generate more weird symtab entries.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/156430044

E.g., here's the new "go build" output:

$ go build misc/cgo/errors/issue8442.go
# command-line-arguments
could not determine kind of name for C.issue8442foo

gcc errors for preamble:
misc/cgo/errors/issue8442.go:11:19: error: unknown type name 'UNDEF'

Fixes #8442.

LGTM=iant
R=iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/129160043

In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.

Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage	within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs.  Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases.  Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.

Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.

Fixes #8428.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043

Fixes #7757.
Fixes #8488.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/118690044

Fixes #5242.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/125120043

This makes GCC behavior (and cgo build failures) deterministic.

Fixes #8487.

Ran this shell command on linux/amd64 (Ubuntu 12.04) before and
after this change:

    for x in `seq 100`; do
      go tool cgo -debug-gcc=true issue8441.go 2>&1 | md5sum
    done | sort | uniq -c

Before:
    67 2cdcb8c7c4e290f7d9009abc581b83dd  -
    10 9a55390df94f7cec6d810f3e20590789  -
    10 acfad22140d43d9b9517bbc5dfc3c0df  -
    13 c337f8fee2304b3a8e3158a4362d8698  -

After:
    100 785c316cbcbcd50896695050e2fa23c1  -

LGTM=minux, iant
R=golang-codereviews, bradfitz, minux, iant
CC=golang-codereviews
https://golang.org/cl/126990043

Fixes #8478.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/122150043

Instead of immediately completing pointer type mappings, add them to
a queue to allow them to be completed later.  This fixes issues	caused
by Type() returning arbitrary in-progress type mappings.

Fixes #8368.
Fixes #8441.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/122850043

Instead of including <sys/types.h> to get size_t, instead include
the ISO C standard <stddef.h> header, which defines fewer additional
types at risk of colliding with the user code.  In particular, this
prevents collisions between <sys/types.h>'s userspace definitions with
the kernel definitions needed by defs_linux.go.

Also, -cdefs mode uses #pragma pack, so we can keep misaligned fields.

Fixes #8477.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/120610043

Update #6677

When a struct contains an anonymous union, use the type and
name of the first field in the union.

This should make the glibc <sys/resource.h> file work; in that
file struct rusage has fields like

__extension__ union
{
        long int ru_maxrss;
        __syscall_slong_t __ru_maxrss_word;
};

in which the field that matters is ru_maxrss and
__ru_maxrss_word just exists to advance to the next field on
systems where the kernel uses long long fields but userspace
expects long fields.

LGTM=mikioh.mikioh
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/106260044

Fixes #8148.

LGTM=cookieo9, rsc
R=rsc, cookieo9
CC=golang-codereviews
https://golang.org/cl/103080043

If we see a typedef to an anonymous struct more than once,
presumably in two different Go files that import "C", use the
same Go type name.

Fixes #8133.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/102080043

For incomplete struct S, C.T and C.struct_S were interchangeable in Go 1.2
and earlier, because all incomplete types were interchangeable
(even C.struct_S1 and C.struct_S2).

CL 76450043, which fixed issue 7409, made different incomplete types
different from Go's point of view, so that they were no longer completely
interchangeable.

However, imprecision about C.T and C.struct_S - really the same
underlying C type - is the one behavior enabled by the bug that
is most likely to be depended on by existing cgo code.
Explicitly allow it, to keep that code working.

Fixes #7786.

LGTM=iant, r
R=golang-codereviews, iant, r
CC=golang-codereviews
https://golang.org/cl/98580046

Fixes #7560.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/96300045

cgo represents all 0-sized and unsized types internally as [0]byte. This means that pointers to incomplete types would be interchangable, even if given a name by typedef.

Fixes #7409.

LGTM=iant
R=golang-codereviews, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/76450043

Clang does not record the "size" field for pointer types,
so we must insert the size ourselves. We were already
doing this, but only for the case of pointer types.
For an array of pointer types, the setting of the size for
the nested pointer type was happening after the computation
of the size of the array type, meaning that the array type
was always computed as 0 bytes. Delay the size computation.

This bug happens on all Clang systems, not just FreeBSD.
Our test checked that cgo wrote something, not that it was correct.
FreeBSD's default clang rejects array[0] as a C struct field,
so it noticed the incorrect sizes. But the sizes were incorrect
everywhere.

Update testcdefs to check the output has the right semantics.

Fixes #6292.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/22840043

The current Windows build breakage appears to be because
the Windows code should be looking for __cgodebug_data
not ___cgodebug_data. Dodge the question everywhere by
accepting both.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/19780043

This flag was added in January 2010, in CL 181102, to fix issue 497.
(Numbers were just shorter back then.) The fix was for OS X machines
and the llvm-gcc frontend.

In July 2011 we had to change the way we get enum values, because
there were no flags available to force Xcode's llvm-gcc to include the
enum names and values in DWARF debug output.

We now use clang, not llvm-gcc, on OS X machines.
Earlier versions of clang printed a warning about not knowing the flag.
Newer versions of clang now make that an error.

That is:
 - The flag was added for OS X machines.
 - The flag is no longer necessary on OS X machines.
 - The flag now breaks some OS X machines.

Remove it.

I have run the original program from issue 497 successfully
without the flag on both OS X and Linux machines.

Fixes #6678.

R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/18850043

Suggested by iant in earlier CL.

R=golang-dev, bradfitz, iant
CC=golang-dev
https://golang.org/cl/14920052

Fixes #6563.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/14870046

The old approach to determining whether "name" was a type, constant,
or expression was to compile the C program

        name;

and scan the errors and warnings generated by the compiler.
This requires looking for specific substrings in the errors and warnings,
which ties the implementation to specific compiler versions.
As compilers change their errors or drop warnings, cgo breaks.
This happens slowly but it does happen.
Clang in particular (now required on OS X) has a significant churn rate.

The new approach compiles a slightly more complex program
that is either valid C or not valid C depending on what kind of
thing "name" is. It uses only the presence or absence of an error
message on a particular line, not the error text itself. The program is:

        // error if and only if name is undeclared
        void f1(void) { typeof(name) *x; }

        // error if and only if name is not a type
        void f2(void) { name *x; }

        // error if and only if name is not an integer constant
        void f3(void) { enum { x = (name)*1 }; }

I had not been planning to do this until Go 1.3, because it is a
non-trivial change, but it fixes a real Xcode 5 problem in Go 1.2,
and the new code is easier to understand than the old code.
It should be significantly more robust.

Fixes #6596.
Fixes #6612.

R=golang-dev, r, james, iant
CC=golang-dev
https://golang.org/cl/15070043

Replaces CL 14682044.
Fixes #6506.

R=rsc, iant, dave
CC=golang-dev
https://golang.org/cl/14717043

The preamble may want to #define some special symbols
and then #include <sys/types.h> itself. The builtin prolog
also #includes <sys/types.h>, which would break such a
preamble (because the second #include will be a no-op).

The use of sys/types.h in the builtin prolog is new since Go 1.1,
so this should preserve the semantics of more existing cgo
code than we would otherwise.

It also fixes src/pkg/syscall/mkall.sh's use of go tool cgo -godefs
on some Linux systems.

Thanks to fullung@ for identifying the problem.

Fixes #6558.

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/14684044

Ensure that clang always exits with a non-zero status by
giving it something that it always warns about (the statement "1;").

Fixes #6128.

R=golang-dev, iant, minux.ma
CC=golang-dev
https://golang.org/cl/14702043

Fixes #6506.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/14682044

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13420048

Fixes #5272.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13498046