1. 29 Nov, 2016 9 commits
    • Michal Bohuslávek's avatar
      net/http/httptest: fix typo in doc comment · 7a92d0b1
      Michal Bohuslávek authored
      Change-Id: I89f276b32015882437e128814573343a4ca53569
      Reviewed-on: https://go-review.googlesource.com/33615Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      7a92d0b1
    • Robert Griesemer's avatar
      cmd/compile: don't panic on syntax error in select statement · 8fa0d85b
      Robert Griesemer authored
      Fixes #18092.
      
      Change-Id: I54e2da2e0f168c068f5e4a1b22ba508d78259168
      Reviewed-on: https://go-review.googlesource.com/33658
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Run-TryBot: Robert Griesemer <gri@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      8fa0d85b
    • Austin Clements's avatar
      runtime: fall back to /proc/self/auxv in Android libs · 6f287fa2
      Austin Clements authored
      Android's libc doesn't provide access to auxv, so currently the Go
      runtime synthesizes a fake, minimal auxv when loaded as a library on
      Android. This used to be sufficient, but now we depend on auxv to
      retrieve the system physical page size and panic if we can't retrieve
      it.
      
      Fix this by falling back to reading auxv from /proc/self/auxv if the
      loader-provided auxv is empty and removing the synthetic auxv vectors.
      
      Fixes #18041.
      
      Change-Id: Ia2ec2c764a6609331494a5d359032c56cbb83482
      Reviewed-on: https://go-review.googlesource.com/33652
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      6f287fa2
    • Austin Clements's avatar
      runtime: extract Linux auxv handling · d39b7b53
      Austin Clements authored
      This refactoring is in preparation for handling auxv differently in
      Android shared libraries.
      
      Updates #18041.
      
      Change-Id: If0458a309f9c804e7abd0a58b5a224d89f8da257
      Reviewed-on: https://go-review.googlesource.com/33651
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      d39b7b53
    • Brad Fitzpatrick's avatar
      doc: more go1.8.html updates · 5d1c6011
      Brad Fitzpatrick authored
      TBR=See https://golang.org/cl/33244
      
      Updates #17929
      
      Change-Id: I648df63aeb67aa2229c7b4fc23676a78b31140a0
      Reviewed-on: https://go-review.googlesource.com/33657Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      5d1c6011
    • Brad Fitzpatrick's avatar
      doc: update go1.8.html after feedback from Russ · 0c5c7c34
      Brad Fitzpatrick authored
      Address Russ's feedback from https://golang.org/cl/33244
      
      TBR=See https://golang.org/cl/33244
      
      Updates #17929
      
      Change-Id: I708d71f519f6414ecec629d3c273d9e737d8ed50
      Reviewed-on: https://go-review.googlesource.com/33656Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      0c5c7c34
    • Ian Lance Taylor's avatar
      cmd/link: handle STT_COMMON symbols · 45f75950
      Ian Lance Taylor authored
      Tested by running
      
      GOTRACEBACK=2 CGO_CFLAGS="-Wa,--elf-stt-common=yes" go test -ldflags=-linkmode=internal
      
      in misc/cgo/test. That failed before this CL, succeeded after.
      
      I don't think it's worth doing that as a regular test, though,
      especially since only recent versions of the GNU binutils support the
      --elf-stt-common option.
      
      Fixes #18088.
      
      Change-Id: I893d86181faee217b1504c054b0ed3f7c8d977d3
      Reviewed-on: https://go-review.googlesource.com/33653
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      45f75950
    • Russ Cox's avatar
      os: fix handling of Windows Unicode console input and ^Z · 610d5221
      Russ Cox authored
      Go 1.5 worked with Unicode console input but not ^Z.
      Go 1.6 did not work with Unicode console input but did handle one ^Z case.
      Go 1.7 did not work with Unicode console input but did handle one ^Z case.
      
      The intent of this CL is for Go 1.8 to work with Unicode console input
      and also handle all ^Z cases.
      
      Here's a simple test program for reading from the console.
      It prints a "> " prompt, calls read, prints what it gets, and repeats.
      
      	package main
      
      	import (
      	    "fmt"
      	    "os"
      	)
      
      	func main() {
      	    p := make([]byte, 100)
      	    fmt.Printf("> ")
      	    for {
      	        n, err := os.Stdin.Read(p)
      	        fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
      	    }
      	}
      
      On Unix, typing a ^D produces a break in the input stream.
      If the ^D is at the beginning of a line, then the 0 bytes returned
      appear as an io.EOF:
      
      	$ go run /tmp/x.go
      	> hello
      	[6 "hello\n" <nil>]
      	> hello^D[5 "hello" <nil>]
      	> ^D[0 "" EOF]
      	> ^D[0 "" EOF]
      	> hello^Dworld
      	[5 "hello" <nil>]
      	> [6 "world\n" <nil>]
      	>
      
      On Windows, the EOF character is ^Z, not ^D, and there has
      been a long-standing problem that in Go programs, ^Z on Windows
      does not behave in the expected way, namely like ^D on Unix.
      Instead, the ^Z come through as literal ^Z characters:
      
      	C:\>c:\go1.5.4\bin\go run x.go
      	> ^Z
      	[3 "\x1a\r\n" <nil>]
      	> hello^Zworld
      	[13 "hello\x1aworld\r\n" <nil>]
      	>
      
      CL 4310 attempted to fix this bug, then known as #6303,
      by changing the use of ReadConsole to ReadFile.
      This CL was released as part of Go 1.6 and did fix the case
      of a ^Z by itself, but not as part of a larger input:
      
      	C:\>c:\go1.6.3\bin\go run x.go
      	> ^Z
      	[0 "" EOF]
      	> hello^Zworld
      	[13 "hello\x1aworld\r\n" <nil>]
      	>
      
      So the fix was incomplete.
      Worse, the fix broke Unicode console input.
      
      ReadFile does not handle Unicode console input correctly.
      To handle Unicode correctly, programs must use ReadConsole.
      Early versions of Go used ReadFile to read the console,
      leading to incorrect Unicode handling, which was filed as #4760
      and fixed in CL 7312053, which switched to ReadConsole
      and was released as part of Go 1.1 and still worked as of Go 1.5:
      
      	C:\>c:\go1.5.4\bin\go run x.go
      	> hello
      	[7 "hello\r\n" <nil>]
      	> hello world
      	[16 "hello world\r\n" <nil>]
      	>
      
      But in Go 1.6:
      
      	C:\>c:\go1.6.3\bin\go run x.go
      	> hello
      	[7 "hello\r\n" <nil>]
      	> hello world
      	[0 "" EOF]
      	>
      
      That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
      which has been refiled as #17097. (We have no automated test
      for this because we don't know how to simulate console input
      in a test: it appears that one must actually type at a keyboard
      to use the real APIs. This CL at least adds a comment warning
      not to reintroduce ReadFile again.)
      
      CL 29493 attempted to fix #17097, but it was not a complete fix:
      the hello world example above still fails, as does Shift-JIS input,
      which was filed as #17939.
      
      CL 29493 also broke ^Z handling, which was filed as #17427.
      
      This CL attempts the never before successfully performed trick
      of simultaneously fixing Unicode console input and ^Z handling.
      It changes the console input to use ReadConsole again,
      as in Go 1.5, which seemed to work for all known Unicode input.
      Then it adds explicit handling of ^Z in the input stream.
      (In the case where standard input is a redirected file, ^Z processing
      should not happen, and it does not, because this code path is only
      invoked when standard input is the console.)
      
      With this CL:
      
      	C:\>go run x.go
      	> hello
      	[7 "hello\r\n" <nil>]
      	> hello world
      	[16 "hello world\r\n" <nil>]
      	> ^Z
      	[0 "" EOF]
      	> [2 "\r\n" <nil>]
      	> hello^Zworld
      	[5 "hello" <nil>]
      	> [0 "" EOF]
      	> [7 "world\r\n" <nil>]
      
      This almost matches Unix:
      
      	$ go run /tmp/x.go
      	> hello
      	[6 "hello\n" <nil>]
      	> hello world
      	[15 "hello world\n" <nil>]
      	> ^D
      	[0 "" EOF]
      	> [1 "\n" <nil>]
      	> hello^Dworld
      	[5 "hello" <nil>]
      	> [6 "world\n" <nil>]
      	>
      
      The difference is in the handling of hello^Dworld / hello^Zworld.
      On Unix, hello^Dworld terminates the read of hello but does not
      result in a zero-length read between reading hello and world.
      This is dictated by the tty driver, not any special Go code.
      
      On Windows, in this CL, hello^Zworld inserts a zero length read
      result between hello and world, which is treated as an interior EOF.
      This is implemented by the Go code in this CL, but it matches the
      handling of ^Z on the console in other programs:
      
      	C:\>copy con x.txt
      	hello^Zworld
      	        1 file(s) copied.
      
      	C:\>type x.txt
      	hello
      	C:\>
      
      A natural question is how to test all this. As noted above, we don't
      know how to write automated tests using the actual Windows console.
      CL 29493 introduced the idea of substituting a different syscall.ReadFile
      implementation for testing; this CL continues that idea but substituting
      for syscall.ReadConsole instead. To avoid the regression of putting
      ReadFile back, this CL adds a comment warning against that.
      
      Fixes #17427.
      Fixes #17939.
      
      Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
      Reviewed-on: https://go-review.googlesource.com/33451
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: default avatarQuentin Smith <quentin@golang.org>
      Reviewed-by: default avatarAlex Brainman <alex.brainman@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      610d5221
    • David Crawshaw's avatar
      os: Executable can use /proc/self/exe on android · 8a2c34e4
      David Crawshaw authored
      Fixes the os test on the Android builder.
      
      Change-Id: Ibb9db712156a620fcccf515e035475c5e2f535a5
      Reviewed-on: https://go-review.googlesource.com/33650
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      8a2c34e4
  2. 28 Nov, 2016 6 commits
  3. 26 Nov, 2016 1 commit
  4. 25 Nov, 2016 1 commit
    • Daniel Martí's avatar
      testing: comment out flag.Parse from example · 11106492
      Daniel Martí authored
      The TestMain docs explain that flag.Parse() should be called if TestMain
      itself depends on command-line flags.
      
      The issue here is that the example implementation does not use any
      flags, and thus the flag.Parse call is unnecessary. This leads to people
      who use this example as a starting point for their own implementations
      to forget that the call is not necessary in most cases.
      
      Comment it out instead of removing the line to keep it as a reminder, as
      suggested by Minux Ma.
      
      Change-Id: I6ffc5413e7036366ae3cf0f069b7065e832a3b45
      Reviewed-on: https://go-review.googlesource.com/33273Reviewed-by: default avatarMinux Ma <minux@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      11106492
  5. 24 Nov, 2016 3 commits
  6. 23 Nov, 2016 8 commits
  7. 22 Nov, 2016 12 commits