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
This is a common task, so it makes sense to have a helper to do it.
(App Engine doesn't like "Transfer-Encoding: chunked" for POST
bodies, which is the default for regular Post.)
R=rsc
CC=golang-dev
https://golang.org/cl/2113041
It's unlikely to affect any extant code, but I wanted to make this API change
before digging in for a rewrite.
R=rsc
CC=golang-dev
https://golang.org/cl/2112041
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
Not a bug per-se, the issue is that the fmt.Sprintf method inside the
ByteSize.String() method ends up calling itself to generate the String
representation of the ByteSize value. Infinite loops are bad.
Updated as per review comments
R=r
CC=golang-dev
https://golang.org/cl/1974046
Two tests start a goroutine which runs exportSend, and then
the tests run importReceive. exportSend creates an export
channel. importReceive asks to receive values on that
channel. Because exportSend runs in a separate goroutine,
it's possible for the export client to receive the request for
values on the channel, from importReceive, before the
goroutine actually creates the export channel. That causes an
error: "export: no such channel: exportedSend". This patch
avoids the race by creating the export channel before starting
the goroutine.
There does not seem to be a similar race condition in the
tests which send data in the other direction.
R=r
CC=golang-dev
https://golang.org/cl/2026045
End the charade (farce?) that we are using upload.py unaltered.
Cut all the unused stuff.
Indent using tabs to match the rest of the file.
Next: rewrite MercurialVCS to use mercurial package,
to avoid overhead of forking off a new hg command
multiple times for every file. And parallelize upload.
R=gri
CC=golang-dev
https://golang.org/cl/2009046
- refine/define Scope, Object, and Type structures
(note: scope.go has the addition of types, the rest is only re-organized
for better readability)
- implemented top-level of type checker:
resolve global type declarations (deal with double decls, cycles, etc.)
- temporary hooks for checking of const/var declarations, function/method bodies
- test harness for fine-grained testing (exact error locations)
with initial set of tests
This is a subset of the code for easier review.
R=rsc
CC=golang-dev
https://golang.org/cl/1967049
