Solves the (English) peg solitaire game. The board is represented
by a 1-dimensional array for easy representation of directions
with a single integer. The board's contents are chosen such that
it can be printed with a direct string() conversion.
R=r
CC=adg, golang-dev
https://golang.org/cl/2066042
bug284.go:33: error: invalid type conversion
bug284.go:36: error: invalid type conversion (cannot use type A2 as type A1)
bug284.go:37: error: invalid type conversion
bug284.go:38: error: invalid type conversion (cannot use type A1 as type A2)
bug284.go:56: error: invalid type conversion
bug284.go:59: error: invalid type conversion (cannot use type S2 as type S1)
bug284.go:60: error: invalid type conversion
bug284.go:61: error: invalid type conversion (cannot use type S1 as type S2)
bug284.go:71: error: invalid type conversion
bug284.go:74: error: invalid type conversion (cannot use type P2 as type P1)
bug284.go:75: error: invalid type conversion
bug284.go:76: error: invalid type conversion (cannot use type P1 as type P2)
bug284.go:96: error: invalid type conversion
bug284.go:99: error: invalid type conversion (cannot use type Q2 as type Q1)
bug284.go:101: error: invalid type conversion (cannot use type Q1 as type Q2)
bug284.go:111: error: invalid type conversion (different parameter types)
bug284.go:114: error: invalid type conversion (different parameter types)
bug284.go:115: error: invalid type conversion (different parameter types)
bug284.go:116: error: invalid type conversion (different parameter types)
bug284.go:134: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:137: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:138: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:139: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:149: error: invalid type conversion
bug284.go:152: error: invalid type conversion (cannot use type L2 as type L1)
bug284.go:153: error: invalid type conversion
bug284.go:154: error: invalid type conversion (cannot use type L1 as type L2)
bug284.go:164: error: invalid type conversion
bug284.go:167: error: invalid type conversion (cannot use type L2 as type L1)
bug284.go:168: error: invalid type conversion
bug284.go:169: error: invalid type conversion (cannot use type L1 as type L2)
bug284.go:179: error: invalid type conversion
bug284.go:182: error: invalid type conversion (cannot use type C2 as type C1)
bug284.go:183: error: invalid type conversion
bug284.go:184: error: invalid type conversion (cannot use type C1 as type C2)
R=rsc
CC=golang-dev
https://golang.org/cl/2136041
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
