Change the term 'standard time', which already means something,
to 'reference time', and add a couple of sentences and clarifications.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8799047
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
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
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
The String method is called whenever the printing operation wants a string,
not just for %s and %v.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8638043
If there are no tags, the rules are the same as before.
If there is a tagged field, choose it if there is exactly one
at the top level of all fields.
More tests. The old tests were clearly inadequate, since
they all pass as is. The new tests only work with the new code.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/8617044
The old code was incorrect and also broken. It passed the tests by accident.
The new algorithm is:
1) Sort the fields in order of names.
2) For all fields with the same name, sort in increasing depth.
3) Choose the single field with shortest depth.
If any of the fields of a given name has a tag, do the above using
tagged fields of that name only.
Fixes#5245.
R=iant
CC=golang-dev
https://golang.org/cl/8583044
Makes it possible to return the spent runtime.PollDesc to
runtime.pollcache descriptor pool when netFD.connect or
syscall.Listen fails.
Fixes#5219.
R=dvyukov, dave, bradfitz, adg
CC=golang-dev
https://golang.org/cl/8318044
The race detector uses a global lock to analyze atomic
operations. A panic in the middle of the code leaves the
lock acquired.
Similarly, the sync package may leave the race detectro
inconsistent when methods are called on nil pointers.
R=golang-dev, r, minux.ma, dvyukov, rsc, adg
CC=golang-dev
https://golang.org/cl/7981043
It's not trivial to make a comprehensive check
due to inferior pointers, reflect, gob, etc.
But this is essentially what I've used to debug
the GC issues.
Update #5193.
R=golang-dev, iant, 0xe2.0x9a.0x9b, r
CC=golang-dev
https://golang.org/cl/8455043
The spec doesn't explicitly say that trailing data is okay, but a lot
of people do this and most unzippers will handle it just fine. In any
case, this makes the package more useful, and led me to make the
directory parsing code marginally more robust.
Fixes#5228.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/8504044
Use atomic operations on flags field to make sure we aren't
losing a flag update during parallel map operations.
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/8377046
It changes an exported API, and breaks the build.
««« original CL description
reflect: use unsafe.Pointer in StringHeader and SliceHeader
Relates to issue 5193.
R=r
CC=golang-dev
https://golang.org/cl/8363045
»»»
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8357051
The invariant is that there must be at least one running P or a thread polling network.
It was broken.
Fixes#5216.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/8459043
This makes it an unsafe.Pointer in Go so the garbage collector
will treat it as a pointer to untyped data, not a pointer to
bytes.
R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/8286045
