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
Before, an empty TMPDIR would lead to:
cannot create <nil>/go.o: No such file or directory
R=golang-dev, iant, dave, bradfitz
CC=golang-dev
https://golang.org/cl/8355045
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
If for whatever reason seh points into Go heap region,
the dangling pointer will cause memory corruption during GC.
Update #5193.
R=golang-dev, alex.brainman, iant
CC=golang-dev
https://golang.org/cl/8402045
The offset of an embedded field s.X must be relative to s
and not to the implicit s.Field of which X is a direct field.
Moreover, no indirections may happen on the path.
Fixes#4909.
R=nigeltao, ality, daniel.morsing, iant, gri, r
CC=golang-dev
https://golang.org/cl/8287043
We've decided to leave logging to third-parties (there are too
many formats), which others have done.
And we can't change the behavior of the various response
fields at this point anyway. Plus I argue they're correct and
match their documention.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8391043
The compilers used to generate only one 'm' symbol
to record the stack frame size for each function.
In cmd/nm, the 'm' and 'f' symbols are handled in
the same switch case with a special exception for
the symbol described above called ".frame".
Now that the compilers emit additional 'm' symbols
for precise garbage collection of the stack, the
current logic is incorrect. cmd/nm will attempt to
interpret these new 'm' symbols as 'f' symbols and
add them to the file name index table.
This fails with an out-of-memory condition when
zenter encounters an 'm' symbol with a very large
value (usually the .args symbol indicating a
variadic NOSPLIT function).
R=iant
CC=dave, gobot, golang-dev, rsc
https://golang.org/cl/7962045
Fixes#5175.
Race detector runtime expects values passed to MapShadow() to be page-aligned,
because they are used in mmap() call. If they are not aligned mmap() trims
either beginning or end of the mapping.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8325043
Also:
- put GORACE into the go env command
- do minor housekeeping on the race detector article
Fixes#4995.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/8319044
- comment fixes
- s/z/x/ in (*rat).Float64 to match convention for functions
returning a non-*Rat
- minor test output tweaking
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8327044
The smtp package originally allowed PLAIN whenever, but then
the TLS check was added for paranoia, but it's too paranoid:
it prevents using PLAIN auth even from localhost to localhost
when the server advertises PLAIN support.
This CL also permits the client to send PLAIN if the server
advertises it.
Fixes#5184
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8279043
Save an allocation per GET request and don't call io.LimitedReader(r, 0)
just to read 0 bytes. There's already an eofReader global variable
for when we just want a non-nil io.Reader to immediately EOF.
(Sorry, I know Rob told me to stop, but I was bored on the plane and
wrote this before I received the recent "please, really stop" email.)
benchmark old ns/op new ns/op delta
BenchmarkServerHandlerTypeLen 13888 13279 -4.39%
BenchmarkServerHandlerNoLen 12912 12229 -5.29%
BenchmarkServerHandlerNoType 13348 12632 -5.36%
BenchmarkServerHandlerNoHeader 10911 10261 -5.96%
benchmark old allocs new allocs delta
BenchmarkServerHandlerTypeLen 20 19 -5.00%
BenchmarkServerHandlerNoLen 18 17 -5.56%
BenchmarkServerHandlerNoType 18 17 -5.56%
BenchmarkServerHandlerNoHeader 13 12 -7.69%
benchmark old bytes new bytes delta
BenchmarkServerHandlerTypeLen 1913 1878 -1.83%
BenchmarkServerHandlerNoLen 1878 1843 -1.86%
BenchmarkServerHandlerNoType 1878 1844 -1.81%
BenchmarkServerHandlerNoHeader 1085 1051 -3.13%
Fixes#5188
R=golang-dev, adg, r
CC=golang-dev
https://golang.org/cl/8297044
My old code was trying to be too smart.
Also: Slightly better error message format
for gofmt -r pattern errors.
Fixes#4406.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/8267045
This changes the map lookup behavior for string maps with 2-8 keys.
There was already previously a fastpath for 0 items and 1 item.
Now, if a string-keyed map has <= 8 items, first check all the
keys for length first. If only one has the right length, then
just check it for equality and avoid hashing altogether. Once
the map has more than 8 items, always hash like normal.
I don't know why some of the other non-string map benchmarks
got faster. This was with benchtime=2s, multiple times. I haven't
anything else getting slower, though.
benchmark old ns/op new ns/op delta
BenchmarkHashStringSpeed 37 34 -8.20%
BenchmarkHashInt32Speed 32 29 -10.67%
BenchmarkHashInt64Speed 31 27 -12.82%
BenchmarkHashStringArraySpeed 105 99 -5.43%
BenchmarkMegMap 274206 255153 -6.95%
BenchmarkMegOneMap 27 23 -14.80%
BenchmarkMegEqMap 148332 116089 -21.74%
BenchmarkMegEmptyMap 4 3 -12.72%
BenchmarkSmallStrMap 22 22 -0.89%
BenchmarkMapStringKeysEight_32 42 23 -43.71%
BenchmarkMapStringKeysEight_64 55 23 -56.96%
BenchmarkMapStringKeysEight_1M 279688 24 -99.99%
BenchmarkIntMap 16 15 -10.18%
BenchmarkRepeatedLookupStrMapKey32 40 37 -8.15%
BenchmarkRepeatedLookupStrMapKey1M 287918 272980 -5.19%
BenchmarkNewEmptyMap 156 130 -16.67%
R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/7641057
It was unnecessarily cloning and then mutating a map that had
a very short lifetime (just that function).
No new tests, because they were added in revision 833bf2ef1527
(TestHeaderToWire). The benchmarks below are from the earlier
commit, revision 52e3407d.
I noticed this inefficiency when reviewing a change Peter Buhr
is looking into, which will also use these benchmarks.
benchmark old ns/op new ns/op delta
BenchmarkServerHandlerTypeLen 12547 12325 -1.77%
BenchmarkServerHandlerNoLen 12466 11167 -10.42%
BenchmarkServerHandlerNoType 12699 11800 -7.08%
BenchmarkServerHandlerNoHeader 11901 9210 -22.61%
benchmark old allocs new allocs delta
BenchmarkServerHandlerTypeLen 21 20 -4.76%
BenchmarkServerHandlerNoLen 20 18 -10.00%
BenchmarkServerHandlerNoType 20 18 -10.00%
BenchmarkServerHandlerNoHeader 17 13 -23.53%
benchmark old bytes new bytes delta
BenchmarkServerHandlerTypeLen 1930 1913 -0.88%
BenchmarkServerHandlerNoLen 1912 1879 -1.73%
BenchmarkServerHandlerNoType 1912 1878 -1.78%
BenchmarkServerHandlerNoHeader 1491 1086 -27.16%
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/8268046
A package file may begin as either "package foo" or
"package foo safe". The latter is relevant when using -u.
https://golang.org/cl/6903059 resulted in the distinction
being dropped when a package was read for the second or later time.
This CL records whether that "safe" tag was present,
and includes it in the dummy statement generated for the lexer.
R=golang-dev, r, minux.ma, daniel.morsing, iant
CC=golang-dev
https://golang.org/cl/8255044
The expected precision setting for the x87 on Win32 is 53-bit
but MinGW resets the floating point unit to 64-bit. Win32
object code generally expects values to be rounded to double,
not double extended, precision.
R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/8175044
