The new build tag "go1.1" will be satisfied by any Go 1.z release >= 1.1.
In general, the build tag "go1.x" will be satisfied by any Go 1.z release >= 1.x.
What happens when we reach Go 2 is yet to be decided.
The tags "go1" or "go1.0" are missing, because +build tags did not exist
before then, and also because the Go 1.0 releases do not recognize them.
The new -installsuffix flag gives access to the build context's InstallSuffix
(formerly named InstallTag, but not part of Go 1.0), for use in isolating
builds to custom directories. For example -race implies -installsuffix race,
and an AppEngine-specific build might use -tags appengine -installsuffix appengine.
Fixes#4116.
Fixes#4443.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/7794043
Eliminate false positives when you can tell even without
type information that the literal does not need field tags.
Far too noisy otherwise.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7797043
valgrind complained that under some circumstances,
*nr = *nc
was being called when nr and nc were the same *Node. The suggestion my Rémy was to introduce a tmp node to avoid the potential for aliasing in subnode.
R=remyoudompheng, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7780044
If a fixed size array is passed in as the decode target and the JSON
to decode has extra array elements that are objects, then previously
the decoder would return a "data changing underfoot" error.
Fixes#3717.
R=golang-dev, adg, rsc
CC=golang-dev
https://golang.org/cl/7490046
Correctly indent the body of functions that have been declared
over multiple lines. See http://play.golang.org/p/MHMwNDbFyf for
an example.
Previously, the body of the function would be indented as deep as
the continuation line of the function declaration. Now it gets
indented as deep as the func keyword.
R=adonovan, cw, patrick.allen.higgins
CC=golang-dev
https://golang.org/cl/7628043
Fixes#4705.
Note that libjpeg will print a warning to stderr if there are many
extraneous bytes, but can be silent if the extraneous bytes can fit
into its int32 bit-buffer for Huffman decoding. I'm guessing that
this is why whatever encoder that produced the image filed for issue
4705 did not realize that they are, strictly speaking, generating an
invalid JPEG. That issue's attached image has two extraneous bytes.
For example, piping the program below into libjpeg's djpeg program
will print an "18 extraneous bytes" warning, even though N == 20.
$ cat main.go
package main
import (
"bytes"
"image"
"image/color"
"image/jpeg"
"os"
)
const N = 20
func main() {
// Encode a 1x1 red image.
m := image.NewRGBA(image.Rect(0, 0, 1, 1))
m.Set(0, 0, color.RGBA{255, 0, 0, 255})
buf := new(bytes.Buffer)
jpeg.Encode(buf, m, nil)
b := buf.Bytes()
// Strip the final "\xff\xd9" EOI marker.
b = b[:len(b)-2]
// Append N dummy 0x80 bytes to the SOS data.
for i := 0; i < N; i++ {
b = append(b, 0x80)
}
// Put back the "\xff\xd9" EOI marker.
b = append(b, 0xff, 0xd9)
os.Stdout.Write(b)
}
$ go run main.go | djpeg /dev/stdin > /tmp/foo.pnm
Corrupt JPEG data: 18 extraneous bytes before marker 0xd9
The resultant /tmp/foo.pnm is a perfectly good 1x1 red image.
R=r
CC=golang-dev
https://golang.org/cl/7750043
With the global redefinition of runtime·open by CL 7543043,
we need to provide a third argument and remove the cast
to the string.
Fixes build on 386 version of Plan 9.
R=khr, rsc, rminnich, ality
CC=golang-dev
https://golang.org/cl/7644047
Many thanks to Elias Naur for finding this with Valgrind on Linux.
Perhaps this is what is breaking the windows/amd64 builder.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7595044
The parameter list layout function was incorrectly computing the
end of the previous line in cases where a parameter type spanned
multiple lines. As a result, an extra (valid, but not needed)
comma was introduced before the paremeter list's closing parenthesis.
Fixes#4533.
R=rsc
CC=golang-dev
https://golang.org/cl/7674044
This was a bug that didn't manifest itself before CL 7674044;
but with that CL and without this fix, the go/doc tests fail.
(The bug fixed by 7674044 and the bug fixed here cancelled
each other out w/ respect to the go/doc tests).
R=rsc
CC=golang-dev
https://golang.org/cl/7628045
Uses AES hardware instructions on 386/amd64 to implement
a fast hash function. Incorporates a random key to
thwart hash collision DOS attacks.
Depends on CL#7548043 for new assembly instructions.
Update #3885
Helps some by making hashing faster. Go time drops from
0.65s to 0.51s.
R=rsc, r, bradfitz, remyoudompheng, khr, dsymonds, minux.ma, elias.naur
CC=golang-dev
https://golang.org/cl/7543043
If two fields have the same name but different explicit name spaces,
treat as non-conflicting. This allows parsing common XML formats
that have ns1:tag and ns2:tag in the same XML element.
Fixes#4691.
Allow setting the default name space for unadorned tags, by
writing to Decoder.DefaultSpace. This allows turned the job of
parsing common XML formats that have tag and ns2:tag in the
same XML element into the first case by setting DefaultSpace="ns1".
Fixes#3703.
Use name space attributes when decoding.
Attach name space to attributes when encoding.
Could be done with fewer annotations, but semantically correct as is.
Fixes#3526.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7227056
The issue was that scvg is assigned *after* the scavenger goroutine is started,
so when the scavenger calls entersyscall() the g==scvg check can fail.
Fixes#5025.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7629045
The problem is that there are lots of dead G's from previous tests,
each dead G consumes 1 stack segment.
Fixes#5034.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7749043
Adds a new reader to filter newlines, which fixes errors seen in the
decoder chunking code. Found additional issues with whitespace handling
after the first padding character.
Fixes#4779.
R=minux.ma, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/7311069
The system call takes an int, but the kernel stores it in a uint16.
At least one Linux system sets /proc/sys/net/core/somaxconn
to 262144, which ends up being 0 in the uint16. Avoid being tricked.
FreeBSD sources also store the backlog in a uint16.
Assume the problem is systemic and fix it everywhere.
Fixes#5030.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7480046
The old code just assumed that the only thing
you can embed is a struct. Not true.
Fixes#3803.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/7743043
This isn't as bad as it used to be, but add a bit
more detail to close the issue.
Fixes#3359
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/7606044
