CL 7799045 relaxed the restriction in cmd/go on ~ in GOPATH
to allow paths with ~ in the middle while continuing to
protect against the common mistake of using GOPATH='~/home'
instead of GOPATH=~/home. Unfortunately go/build still
filters these paths out:
$ GOPATH=/tmp/test~ing go build
test.go:22:2: cannot find package "test" in any of:
/usr/lib/go/test (from $GOROOT)
($GOPATH not set)
So relax the requirement in go/build, too.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7826043
NEGL does a negation of the bottom 32 bits and then zero-extends to 64 bits,
resulting in a negative 32-bit number but a positive 64-bit number.
NEGQ does a full 64-bit negation, so that the result is negative both as
a 32-bit and as a 64-bit number.
This doesn't matter for the functions that are declared to return int32.
It only matters for the ones that return int64 or void* [sic].
This will fix the current incorrect error in the OpenBSD/amd64 build.
The build will still be broken, but it won't report a bogus error.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7536046
The database/sql/driver docs make this promise:
"Conn is a connection to a database. It is not used
concurrently by multiple goroutines."
That promises exists as part of database/sql's overall
goal of making drivers relatively easy to write.
So far this promise has been kept without the use of locks by
being careful in the database/sql package, but sometimes too
careful. (cf. golang.org/issue/3857)
The CL associates a Mutex with each driver.Conn, and with the
interface value progeny thereof. (e.g. each driver.Tx,
driver.Stmt, driver.Rows, driver.Result, etc) Then whenever
those interface values are used, the Locker is locked.
This CL should be a no-op (aside from some new Lock/Unlock
pairs) and doesn't attempt to fix Issue 3857 or Issue 4459,
but should make it much easier in a subsequent CL.
Update #3857
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/7803043
Bring net/fd_linux.go back (it was deleted this morning)
because it is still needed for ARM.
Fix a few typos in the runtime reorg.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7759046
thread_GOOS.c becomes os_GOOS.c.
signal_GOOS_GOARCH.c becomes os_GOOS_GOARCH.c,
but with non-GOARCH-specific code moved into os_GOOS.c.
The actual arch-specific signal handler moves into signal_GOARCH.c
to avoid per-GOOS duplication.
New files signal_GOOS_GOARCH.h provide macros for
accessing fields of the very system-specific signal info structs.
Lots moving, but nothing changing.
This is a preliminarly cleanup so I can work on the signal
handling code to fix some open issues without having to
make each change 13 times.
Tested on Linux and OS X, 386 and amd64.
Will fix Plan 9, Windows, and ARM after the fact if necessary.
(Plan 9 and Windows should be fine; ARM will probably have some typos.)
Net effect: -1081 lines of code.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7565048
The problem is that new network poller can have spurious
rediness notifications. This implementation ensures that
the socket is actually connected.
R=golang-dev, rsc, akumar
CC=golang-dev
https://golang.org/cl/7785043
An earlier CL disallowed ~ anywhere in GOPATH, to avoid
problems with GOPATH='~/home' instead of GOPATH=~/home.
But ~ is only special in the shell at the beginning of each of
the paths in the list, and some paths do have ~ in the middle.
So relax the requirement slightly.
Fixes#4140.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/7799045
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
