For some long filenames the USTAR-split code does not work
correctly. It is wrongly assumed that the path would not be too long,
but it is.
The user visible result was that a filename was split, but it still
caused an error.
The cause was a wrongly calculated nlen. In addition I noticed that
at this place it is also seems necessary to check if the prefix will
fit in the 155 chars available for the prefix.
R=dsymonds, rsc
CC=golang-dev
https://golang.org/cl/13300046
Old example referenced global var from multiSorter.Sort and ignored it's argument.
Changed one of example calls to actually pass slice to sort.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/13551044
* Sort imports by import path, then import name, then comment. Currently, gofmt sorts only by import path.
* If two imports have the same import path and import name, and one of them has no comment, remove the import with no comment. (See the discussion at issue 4414.)
Based on @rsc's https://golang.org/cl/7231070/Fixes#4414.
R=gri, rsc
CC=golang-dev
https://golang.org/cl/12837044
This message was helpful for pre-Go 1 users updating to Go 1.
That time is past. Now the message is confusing because it
depends on knowing what pre-Go 1 looked like.
Update #4697.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13335051
Make sure we never pass a timer into timerproc with
a negative duration since it will cause other timers
to never expire.
Fixes#5321.
R=golang-dev, minux.ma, remyoudompheng, mikioh.mikioh, r, bradfitz, rsc, dvyukov
CC=golang-dev
https://golang.org/cl/9035047
O_SYNC changes only on linux-arm (and linux-arm-cgo), but
changes to match O_SYNC on linux-{386,amd64} and what Linux
upstream now uses. See discussion and links on
https://golang.org/cl/13261050/
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13575045
But keep their case for ease of searching.
They were added recently. We don't want them part of go1.2's API.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13569044
cmd/cc: bv.c imports libc.h twice
When using the Plan 9 compiler, the invocation
#include <../ld/textflag.h>
works for the toolchain, but not for the MACH library.
Module cmd/cc/bv.c includes libc.h and "cc.h", which in
turn also includes libc.h. In the Plan 9 context, this
causes a number of duplicate definitions.
R=golang-dev, rsc, r
CC=golang-dev
https://golang.org/cl/13303047
These tests were suggested in golang.org/issue/6080.
They were fixed as part of the new nil pointer checks
that I added a few weeks ago.
Recording the tests as part of marking the issue closed.
Fixes#6080.
R=golang-dev, r, bradfitz
CC=golang-dev
https://golang.org/cl/13255049
Flushing after every token negates the point of buffering. A different approach is required.
««« original CL description
encoding/xml: flush buffer after encoding token
R=rsc, bradfitz, adg
CC=golang-dev
https://golang.org/cl/13004046
»»»
R=golang-dev, adg, rsc
CC=golang-dev
https://golang.org/cl/13515043
This should have been part of revision 16731:cdedb129e020, but
I missed it. This fixes printing local variables when doing
an external link.
No test because we aren't doing any debug info testing yet.
Fixes#5719.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13464046
DeepEqual caches addresses of compared values
each time it visits addressable values. This is
more expensive than actually comparing them in
the common case of large slices of bytes or integers.
Also add a fast path for slices with identical
underlying array.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13000044
The underlying parse tree is visible in text/template, so it should be visible here.
Done by copying the underlying *parse.Tree up to the top level of the struct, and then making sure it's kept up to date.
Fixes#6318.
R=mikesamuel
CC=golang-dev
https://golang.org/cl/13479044
Based on an old suggestion by rsc, it compares the second
and following arguments to the first.
Unfortunately the code cannot be as pretty as rsc's original
because it doesn't require identical types.
R=golang-dev, dsymonds, adg
CC=golang-dev
https://golang.org/cl/13509046
This CL makes resolveInternetAddr return a list of addresses that
contain a pair of different address family IP addresses if possible,
but doesn't contain any API behavioral changes yet. A simple IP
address selection mechanism for Resolve{TCP,UDP,IP}Addr and Dial API
still prefers IPv4.
This is in preparation for TCP connection setup with fast failover on
dual IP stack node as described in RFC 6555.
Update #3610
Update #5267
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13374043
Update #4805
Add the ability to set an open connection limit.
Fixed case where the Conn finalCloser was being called with db.mu locked.
Added separate benchmarks for each path for Exec and Query.
Replaced slice based idle pool with list based idle pool.
R=bradfitz
CC=golang-dev
https://golang.org/cl/10726044
This change allows people who want to parse or set odd X.509 extensions
to do so without having to add support for them all to the package.
I tried to make it so that only a single member: Extensions would be
needed. However, that would mean detecting when the caller had altered
the contents of it so that parsing and marshaling a certificate
wouldn't ignore all changes to the other members. This ended up being
messy, thus the current design where there are two members: one for
reading and another for writing.
As crypto/x509 adds support for more extensions in the future, the raw
extensions will still be in Extensions for older code that expects it
there. Also, future extensions will be overridden by any raw extensions
added to ExtraExtensions by code that was written before support was
added.
R=golang-dev, r
CC=golang-dev, jpsugar
https://golang.org/cl/12056043
Also introduce BGET2/4, BPUT2/4 as they are widely used.
Slightly improve BGETC/BPUTC implementation.
This gives ~5% CPU time improvement on go install -a -p1 std.
Before:
real user sys
0m23.561s 0m16.625s 0m5.848s
0m23.766s 0m16.624s 0m5.846s
0m23.742s 0m16.621s 0m5.868s
after:
0m22.999s 0m15.841s 0m5.889s
0m22.845s 0m15.808s 0m5.850s
0m22.889s 0m15.832s 0m5.848s
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/12745047
