bug278.go:18: error: invalid left hand side of assignment
bug278.go:19: error: array is not addressable
bug278.go:21: error: invalid left hand side of assignment
bug278.go:22: error: invalid left hand side of assignment
R=rsc
CC=golang-dev
https://golang.org/cl/2122042
The gccgo compiler is smart enough to not make something which
is not used. Use global variables to defeat this
optimization.
R=rsc
CC=golang-dev
https://golang.org/cl/2129041
Another case where gccgo and gc report similar but not
identical errors for a recursive interface.
bug251.go:11: error: invalid recursive interface
R=rsc
CC=golang-dev
https://golang.org/cl/2094041
This introduces GC_ERROR to mark an error only issued by the
gc compiler. GCCGO_ERROR already exists to mark errors only
issued by the gccgo compiler. Obviously these should be used
sparingly.
bug195.go:9: error: interface contains embedded non-interface
bug195.go:12: error: interface contains embedded non-interface
bug195.go:15: error: interface contains embedded non-interface
bug195.go:18: error: invalid recursive interface
bug195.go:22: error: invalid recursive interface
R=rsc
CC=golang-dev
https://golang.org/cl/2040043
Also, if the header is bad, exit with a non-zero status.
Other calls to Brdline in the tree, by category:
Reading symbol name from object file:
./cmd/5l/obj.c:486: name = Brdline(f, '\0');
./cmd/6l/obj.c:535: name = Brdline(f, '\0');
./cmd/8l/obj.c:564: name = Brdline(f, '\0');
./libmach/sym.c:292: cp = Brdline(bp, '\0');
Reading archive header line (fixed, short):
./cmd/gc/lex.c:287: if((a = Brdline(b, '\n')) == nil)
./cmd/gc/lex.c:303: if((p = Brdline(b, '\n')) == nil)
Reading object file header line (fixed, short):
./cmd/ld/lib.c:421: line = Brdline(f, '\n');
Reading undefined symbol list (unused code):
./cmd/ld/lib.c:773: while((l = Brdline(b, '\n')) != nil){
Implementing Brdstr:
./libbio/brdstr.c:36: p = Brdline(bp, delim);
The symbol names ones will cause a problem loudly if they
fail: they'll error out with symbol name too long. This means
that you can't define an enormous struct without giving the
type a name and then stick it in an interface, because the
type's symbol name will be too long for the object file.
Since this will be a loud failure instead of a silent one,
I'm willing to wait until it comes up in practice.
R=r
CC=golang-dev
https://golang.org/cl/1982041
these tests work fine on n1 and gumstix. it's unclear
why they keep failing on the godashboard build.
R=rsc
CC=golang-dev
https://golang.org/cl/1664056
Background: The current spec is imprecise with respect to the parsing ambiguity
for composite literals: It says that the ambiguity arises when the TypeName form
of the LiteralType is used. The following code:
if (B) {} ...
is not using the TypeName form (but the parenthesized TypeName form) and thus
could be interpreted as:
if ((B){}) ...
instead of
if B {} ...
Both compilers and gofmt choose the latter interpretation. One could fix the
spec by making the clause regarding the parsing ambiguity more precise ("...using
the _possibly parenthesized_ TypeName form of the LiteralType..."). The alternative
(chosen here) is to simply disallow parenthesized literal types. Except for a single
test case (test/parentype.go) there appears to be no Go code under $GOROOT containing
parenthesized literal types. Furthermore, parentheses are never needed around a
literal type for correct parsing.
R=golang-dev
CC=golang-dev
https://golang.org/cl/1913041
of syscall.Syscall and syscall.SYS_KILL.
In RTEMS, there is no syscall.Syscall support, but it does
support POSIX signals. So, if this testcase is changed to use
syscall.Kill, then it would run fine on RTEMS, when using gccgo.
R=rsc, iant
CC=golang-dev
https://golang.org/cl/1863046
but with less precision than hardware counterparts.
fixed a number of tests to output BUG when they failed.
changed the runner to distinghuish between output
and output containing ^BUG
R=rsc
CC=dho, golang-dev
https://golang.org/cl/1778041
