| Age | Commit message (Collapse) | Author |
|---|
|
The rename ones needed redoing.
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5698054
|
|
X ,s;^// \$G (\$D/)?\$F\.go *$;// compile;g
X ,s;^// \$G (\$D/)?\$F\.go && \$L \$F\.\$A *$;// build;g
X ,s;^// \$G (\$D/)?\$F\.go && \$L \$F\.\$A && \./\$A\.out *$;// run;g
X ,s;^// errchk \$G( -e)? (\$D/)?\$F\.go *$;// errorcheck;g
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5671080
|
|
The ken directory is untouched so we have some examples with explicit semis.
R=gri
CC=golang-dev
https://golang.org/cl/2157041
|
|
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
|
|
allow parens around [...]int in struct literal.
R=ken
OCL=35112
CL=35130
|
|
per discussion with gri.
R=ken
OCL=35108
CL=35108
|
|
plus significant hand editing.
Back to T{x} for composite literals.
R=r
OCL=25612
CL=25632
|
|
examples:
chan <- (chan int)
chan (<- chan int)
(map[string]func())("a": main)
R=ken
OCL=25151
CL=25151
|
