Also add a new variable ErrNoProgress that io.Readers can use to
report ineffectual Read calls.
Fixes#5310.
R=golang-dev, dsymonds, bradfitz
CC=golang-dev
https://golang.org/cl/8845043
I read docs and wrote a crawler + link checker on the plane,
which also checks for #fragments. I'll send that out later
when it's less gross.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8729050
https://golang.org/cl/8134043 disabled cgo when cross compiling, this means builders which compile for both amd64 and 386 will be compiling the latter with cgo disabled.
This proposal modifies the builder to mirror the dist tool by always doing a native build.
Tested on my darwin/amd64 builder and confirmed the result when building darwin/386 is a native 386 build with cgo enabled.
R=bradfitz, dsymonds, r, adg
CC=golang-dev
https://golang.org/cl/8842044
Late bug fix, but this is arguably a regression from Go 1.0,
since we added this transparent decoding since then. Without
this fix, Go 1.0 users could decode this correctly, but Go 1.1
users would not be able to.
The newly added test is from the RFC itself.
The updated tests had the wrong "want" values before. They
were there to test \r\n vs \n equivalence (which is
unchanged), not leading whitespace.
The skipWhite decoder struct field was added in the battles of
Issue 4771 in revision b3bb265bfecf. It was just a wrong
strategy, from an earlier round of attempts in
https://golang.org/cl/7300092/
Update #4771Fixes#5295
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8536045
From the issue, which describes it as well as I could:
database/sql assumes that driver.Stmt.Close does not need the
connection.
see database/sql/sql.go:1308:
This puts the Rows' connection back into the idle pool, and
then calls the driver.Stmt.Close method of the Stmt it belongs
to. In the postgresql driver implementation
(https://github.com/lib/pq), Stmt.Close communicates with the
server (on the connection that was just put back into the idle
pool). Most of the time, this causes no problems, but if
another goroutine makes a query at the right (wrong?) time,
chaos results.
In any case, traffic is being sent on "free" connections
shortly after they are freed, leading to race conditions that
kill the driver code.
Fixes#5283
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8633044
They caused internal compiler errors and they're expensive enough that inlining them doesn't make sense.
Fixes#5259.
R=golang-dev, r, iant, remyoudompheng
CC=golang-dev
https://golang.org/cl/8636043
Debug output from go test -x may contain empty arguments.
This CL quotes arguments if needed. E.g. the output of
go test -x is now
.../6g -o ./_go_.6 -p testmain -complete -D "" -I . -I $WORK ./_testmain.go
which is easier to grasp.
R=golang-dev, bradfitz, minux.ma, r
CC=golang-dev
https://golang.org/cl/8633043
Debug output from go test -x may contain empty arguments.
This CL quotes arguments if needed. E.g. the output of
go test -x is now
.../6g -o ./_go_.6 -p testmain -complete -D "" -I . -I $WORK ./_testmain.go
which is easier to grasp.
R=golang-dev, bradfitz, minux.ma, r
CC=golang-dev
https://golang.org/cl/8633043
This will let us ask people to rebuild the Go system without
precise GC, and then rebuild and retest their program, to see
if precise GC is causing whatever problem they are having.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8700043
UMTX_OP_WAIT expects that the address points to a uintptr, but
the code in lock_futex.c uses a uint32. UMTX_OP_WAIT_UINT is
just like UMTX_OP_WAIT, but the address points to a uint32.
This almost certainly makes no difference on a little-endian
system, but since the kernel supports it we should do the
right thing. And, who knows, maybe it matters.
R=golang-dev, bradfitz, r, ality
CC=golang-dev
https://golang.org/cl/8699043
