Adds tests for #122590 and updates x/net/http2 to git rev 6a8eb5e2b1 for:
http2: call httptrace.ClientTrace.GetConn in Transport when needed
https://golang.org/cl/122590
http2: fire httptrace.ClientTrace.WroteHeaderField if set
https://golang.org/cl/122816
http2: compare Connection header value case-insensitively
https://golang.org/cl/122588
This also includes the code for graceful shutdown, but it has no
public API surface via net/http, and should not affect any existing
code paths, as it's purely new stuff:
net/http/httputil: don't panic in ReverseProxy unless running under a Server
Prior to the fix to #23643, the ReverseProxy didn't panic with
ErrAbortHandler when the copy to a client failed.
During Go 1.11 beta testing, we found plenty of code using
ReverseProxy in tests that were unprepared for a panic.
Change the behavior to only panic when running under the http.Server
that'll handle the panic.
Updates #23643
Change-Id: Ic1fa8405fd54c858ce8c797cec79d006833a9f7d
Reviewed-on: https://go-review.googlesource.com/122819 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Fri, 6 Jul 2018 20:59:06 +0000 (13:59 -0700)]
cmd/go: add LDFLAGS to cache ID when using cgo
The cgo tool records the value of the CGO_LDFLAGS environment variable
in the generated file, so that the linker can later read and use it.
Therefore, we must add CGO_LDFLAGS to the cache ID, as otherwise
changing CGO_LDFLAGS may cause a build result to be incorrectly read
from the cache, producing a different final program.
Change-Id: Ic89c1edc4069837451a36376710ca9b56fb87455
Reviewed-on: https://go-review.googlesource.com/122520
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Richard Musiol [Thu, 5 Jul 2018 17:55:08 +0000 (19:55 +0200)]
syscall/js: improve panic messages
This commit adds the actual type to the panic message when calling
a method of Value on a Value with a bad type. It also adds better
panic messages to Value.Invoke and Value.Call.
Keith Randall [Sat, 7 Jul 2018 04:38:31 +0000 (21:38 -0700)]
cmd/cgo: check function argument/return types for bad C pointer types
We need to determine whether arguments to and return values from C
functions are "bad" typedef'd pointer types which need to be uintptr
on the Go side.
The type of those arguments are not specified explicitly. As a result,
we never look through the C declarations for the GetTypeID functions
associated with that type, and never realize that they are bad.
However, in another function in the same package there might be an
explicit reference. Then we end up with the declaration being uintptr
in one file and *struct{...} in another file. Badness ensues.
Fix this by doing a 2-pass algorithm. In the first pass, we run as
normal, but record all the argument and result types we see. In the
second pass, we include those argument types also when reading the C
types.
Fixes #24161
Change-Id: I8d727e73a2fbc88cb9d9899f8719ae405f59f753
Reviewed-on: https://go-review.googlesource.com/122575
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Sat, 30 Jun 2018 00:31:37 +0000 (17:31 -0700)]
html/template: ignore untyped nil arguments to default escapers
CL 95215 changed text/template so that untyped nil arguments were no
longer ignored, but were instead passed to functions as expected.
This had an unexpected effect on html/template, where all data is
implicitly passed to functions: originally untyped nil arguments were
not passed and were thus effectively ignored, but after CL 95215 they
were passed and were printed, typically as an escaped version of "<nil>".
This CL restores some of the behavior of html/template by ignoring
untyped nil arguments passed implicitly to escaper functions.
While eliminating one change to html/template relative to earlier
releases, this unfortunately introduces a different one: originally
values of interface type with the value nil were printed as an escaped
version of "<nil>". With this CL they are ignored as though they were
untyped nil values. My judgement is that this is a less common case.
We'll see.
This CL adds some tests of typed and untyped nil values to
html/template and text/template to capture the current behavior.
Updates #18716
Fixes #25875
Change-Id: I5912983ca32b31ece29e929e72d503b54d7b0cac
Reviewed-on: https://go-review.googlesource.com/121815
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Stephan Renatus [Mon, 27 Nov 2017 11:41:10 +0000 (12:41 +0100)]
net/http: add support for SameSite option in http.Cookie
The same-site cookie attribute prevents a cookie from being sent along with
cross-site requests. The main goal is mitigate the risk of cross-origin
information leakage and provides some protection against cross-site request
forgery attacks.
This change adds the option to http.Cookie so it can be stored and
passed to HTTP clients.
net/http: comment handleReadError more, superficially use its argument
Fixes #24201
Change-Id: Ib970c4eeaa90489d014482276a7e5afa94a50741
Reviewed-on: https://go-review.googlesource.com/122675 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Mon, 2 Jul 2018 22:21:35 +0000 (15:21 -0700)]
cmd/compile: ensure that loop condition is detected correctly
We need to make sure that the terminating comparison has the right
sense given the increment direction. If the increment is positive,
the terminating comparsion must be < or <=. If the increment is
negative, the terminating comparison must be > or >=.
Do a few cleanups, like constant-folding entry==0, adding comments,
removing unused "exported" fields.
regexp: revert "use sync.Pool to cache regexp.machine objects"
Revert CL 101715.
The size of a sync.Pool scales linearly with GOMAXPROCS,
making it inappropriate to put a sync.Pool in any individually
allocated object, as the sync.Pool documentation explains.
The change also broke DeepEqual on regexps.
I have a cleaner way to do this with global sync.Pools but it's
too late in the cycle. Will revisit in Go 1.12. For now, revert.
CL 122515 tightened TestAbort to look for breakpoint exceptions and
not just general signal crashes, but this only applies on x86 arches.
On non-x86 arches we use a nil pointer dereference to abort, so the
test is now failing.
This CL re-loosens TestAbort on non-x86 arches to only expect a signal
traceback.
Should fix the build on linux/arm, linux/arm64, linux/ppc64, and
linux/s390x.
Austin Clements [Mon, 25 Jun 2018 22:00:43 +0000 (18:00 -0400)]
runtime: handle g0 stack overflows gracefully
Currently, if the runtime overflows the g0 stack on Windows, it leads
to an infinite recursion:
1. Something overflows the g0 stack bounds and calls morestack.
2. morestack determines it's on the g0 stack and hence cannot grow the
stack, so it calls badmorestackg0 (which prints "fatal: morestack on
g0") followed by abort.
3. abort performs an INT $3, which turns into a Windows
_EXCEPTION_BREAKPOINT exception.
4. This enters the Windows sigtramp, which ensures we're on the g0
stack and calls exceptionhandler.
5. exceptionhandler has a stack check prologue, so it determines that
it's out of stack and calls morestack.
6. goto 2
Fix this by making the exception handler avoid stack checks until it
has ruled out an abort and by blowing away the stack bounds in
lastcontinuehandler before we print the final fatal traceback (which
itself involves a lot of stack bounds checks).
Fixes #21382.
Change-Id: Ie66e91f708e18d131d97f22b43f9ac26f3aece5a
Reviewed-on: https://go-review.googlesource.com/120857
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
runtime: account for guard zone in Windows stack size
Windows includes an 8K guard in system-allocated thread stacks, which
we currently don't account for when setting the g0 stack bounds. As a
result, if we do overflow the g0 stack bounds, we'll get a
STATUS_GUARD_PAGE_VIOLATION exception, which we're not expecting.
Fix the g0 stack bounds to include a total of 16K of slop to account
for this 8K guard.
Updates #21382.
Change-Id: Ia89b741b1413328e4681a237f5a7ee645531fe16
Reviewed-on: https://go-review.googlesource.com/122516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
On Windows, the IP recorded in the breakpoint exception caused by
runtime.abort is actually one byte after the INT3, unlike on UNIX
OSes. Account for this in isgoexception.
It turns out TestAbort was "passing" on Windows anyway because abort
still caused a fatal panic, just not the one we were expecting. This
CL tightens this test to check that the runtime specifically reports a
breakpoint exception.
Fixing this is related to #21382, since we use runtime.abort in
reporting g0 stack overflows, and it's important that we detect this
and not try to handle it.
Change-Id: I66120944d138eb80f839346b157a3759c1019e34
Reviewed-on: https://go-review.googlesource.com/122515
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Ian Lance Taylor [Fri, 29 Jun 2018 21:38:56 +0000 (14:38 -0700)]
os: increase directory reading block size on Unix systems
Reportedly CIFS on RHEL 7 can fail to report files if directories are
read in 4K increments. While this seems to be a CIFS or RHEL bug,
reportedly CIFS does not return more than 5760 bytes in a block, so
reading in 8K increments should hide the problem from users with
minimal cost.
Fixes #24015
Change-Id: Iaf9f00ffe338d379c819ed9edcd4cc9834e3b0f7
Reviewed-on: https://go-review.googlesource.com/121756
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Matthew Dempsky [Fri, 6 Jul 2018 19:14:22 +0000 (12:14 -0700)]
cmd/compile: fix "width not calculated" ICE
Expanding interface method sets is handled during width calculation,
which can't be performed concurrently. Make sure that we eagerly
expand interfaces in the frontend when importing them, even if they're
not actually used by code, because we might need to generate a type
description of them.
Go documentation can have header lines, which are single-line paragraphs
with leading and trailing letters and almost no punctuation.
Before this CL, the only allowed punctuation was ' followed by s.
After this CL, parentheses and commas are also allowed,
to pick up a pair of previously unrecognized headings in the
go command documentation:
Gofmt (reformat) package sources
Modules, module versions, and more
David du Colombier [Fri, 6 Jul 2018 08:46:37 +0000 (10:46 +0200)]
cmd/go: skip gitrepo tests on Plan 9
CL 118095 added gitrepo tests. These tests are failing on Plan 9
since they expect a full-featured git command, while the git tool
has been emulated as a simple rc script on Plan 9.
Fixes #25938.
Change-Id: I262a89d0ce83168c550d9af3e832ed3a1e3c43f6
Reviewed-on: https://go-review.googlesource.com/122455
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Munday [Thu, 5 Jul 2018 13:54:50 +0000 (09:54 -0400)]
misc/cgo/testcarchive: increase timeout duration in TestOsSignal
This test is slightly flaky on the s390x builder and I suspect that
the 100ms timeout is a little too optimistic when the VM is starved.
Increase the timeout to 5s to match the other part of the test.
Fixes #26231.
Change-Id: Ia6572035fb3efb98749f2c37527d250a4c779477
Reviewed-on: https://go-review.googlesource.com/122315
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Daniel Martí [Thu, 5 Jul 2018 16:46:51 +0000 (17:46 +0100)]
net/http: deflake TestServerShutdownStateNew
This function tests that calling Shutdown on a Server that has a "new"
connection yet to write any bytes, in which case it should wait for five
seconds until considering the connection as "idle".
However, the test was flaky. If Shutdown happened to run before the
server accepted the connection, the connection would immediately be
rejected as the server is already closed, as opposed to being accepted
in the "new" state. Then, Shutdown would return almost immediately, as
it had no connections to wait for:
--- FAIL: TestServerShutdownStateNew (2.00s)
serve_test.go:5603: shutdown too soon after 49.41µs
serve_test.go:5617: timeout waiting for Read to unblock
Fix this by making sure that the connection has been accepted before
calling Shutdown. Verified that the flake is gone after 50k concurrent
runs of the test with no failures, whereas the test used to fail around
10% of the time on my laptop:
go test -c && stress -p 256 ./http.test -test.run TestServerShutdownStateNew
Michael Munday [Wed, 4 Jul 2018 15:43:19 +0000 (16:43 +0100)]
cmd/internal/obj/s390x: increase maximum number of loop iterations
The maximum number of 'spanz' iterations that the s390x assembler
performs to reach a fixed point for relative offsets was 10. This
turned out to be too aggressive for one example of auto-generated
fuzzing code. Increase the number of iterations by 10x to reduce
the likelihood that the limit will be hit again. This limit only
exists to help find bugs in the assembler.
master at tip does not fail with the example code in the issue, I
have therefore not submitted it as a test (it is also quite large).
I tested this change with the example code at the commit given and
it fixes the issue.
Ian Lance Taylor [Wed, 4 Jul 2018 05:10:58 +0000 (22:10 -0700)]
cmd/cgo: mark C result as written for msan
Otherwise it is possible that msan will consider the C result to be
partially initialized, which may cause msan to think that the Go stack
is partially uninitialized. The compiler will never mark the stack as
initialized, so without this CL it is possible for stack addresses to
be passed to msanread, which will cause a false positive error from msan.
Nikhil Benesch [Sat, 24 Mar 2018 22:51:01 +0000 (18:51 -0400)]
runtime: support capturing C backtrace from signal handler on darwin/amd64
The implementation is mostly copied from the commit that added
linux/amd64 support for this feature (https://golang.org/cl/17761).
Change-Id: I3f482167620a7a3daf50a48087f8849a30d713bd
Reviewed-on: https://go-review.googlesource.com/102438 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Paul Jolly [Mon, 2 Jul 2018 07:08:14 +0000 (08:08 +0100)]
misc/wasm: use single map for string, symbol and object id mapping.
Currently we use a globally unique symbol property on objects that get
passed from JavaScript to Go to store a unique ID that Go then uses when
referring back to the JavaScript object (via js.Value.ref). This
approach fails however when a JavaScript object cannot be modified, i.e.
cannot have new properties added or is frozen. The test that is added as
part of this commit currently fails with:
Cannot add property Symbol(), object is not extensible
Instead we consolidate the string, symbol and object unique ID mapping
into a single map. Map key equality is determined via strict equality,
which is the semantic we want in this situation.
Change-Id: Ieb2b50fc36d3c30e148aa7a41557f3c59cd33766
Reviewed-on: https://go-review.googlesource.com/121799
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Richard Musiol <neelance@gmail.com>
Daniel Martí [Mon, 30 Apr 2018 05:48:02 +0000 (14:48 +0900)]
cmd/compile: reorganise and improve ssa/README.md
Since the initial version was written, I've gotten help writing
cmd/compile/README.md and I've also learned some more on my own, so it's
time to organise this document better and expand it.
First, split up the document in sections, starting from the simplest
ideas that can be explained on their own. From there, build all the way
up into SSA functions and how they are compiled.
Each of the sections also gets more detail now; most ideas that were a
paragraph are now a section with several paragraphs. No new major
sections have been added in this CL.
While at it, add a copyright notice and make better use of markdown,
just like in the other README.md.
Also fix a file path in value.go, which I noticed to be stale while
reading godocs to write the document.
Finally, leave a few TODO comments for areas that would benefit from
extra input from people familiar with the SSA package. They will be
taken care of in future CLs.
Change-Id: I85e7a69a0b3260e72139991a625d926099624f71
Reviewed-on: https://go-review.googlesource.com/110067 Reviewed-by: Keith Randall <khr@golang.org>
Ian Lance Taylor [Mon, 2 Jul 2018 23:48:29 +0000 (16:48 -0700)]
cmd/go: add ForceLibrary to build hash
When a command has a test that is not in package main, the main
package is built as a library, with ForceLibrary set. It can of course
also be built as an ordinary main package. If we don't record that fact
in the hash, then both variants of the command will use the same hash,
which causes a GODEBUG=gocacheverify=1 failure. It also seems unsafe
although it's not clear to me whether it can cause an actual failure.
Along with CL 121941,
Fixes #25666
Change-Id: I115ad249012f30fbe45cd0c41da86adc295fe4b2
Reviewed-on: https://go-review.googlesource.com/121942
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Than McIntosh [Thu, 28 Jun 2018 20:10:19 +0000 (16:10 -0400)]
cmd/link: split off 'Dynimp' string fields to reduce sym.Symbol size
The linker's sym.Symbol struct contains two string fields, "Dynimplib"
and "Dynimpvers" that are used only in very specific circumstances
(for many symbols, such as DWARF syms, they are wasted space). Split
these two off into a separate struct, then point to an instance of
that struct when needed. This reduces the size of sym.Symbol so as to
save space in the common case.
Updates #26186
Change-Id: Id9c74824e78423a215c8cbc105b72665525a1eff
Reviewed-on: https://go-review.googlesource.com/121916 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Than McIntosh [Thu, 28 Jun 2018 19:42:20 +0000 (15:42 -0400)]
cmd/link: use side table instead of sym.Symbol 'Reachparent' field
The sym.Symbol 'Reachparent' field is used only when field tracking
is enabled. So as to use less memory for the common case where
field tracking is not enabled, remove this field and use a side
table stored in the context to achieve the same functionality.
Updates #26186
Change-Id: Idc5f8b0aa323689d4d51dddb5d1b0341a37bb7d2
Reviewed-on: https://go-review.googlesource.com/121915 Reviewed-by: Ian Lance Taylor <iant@golang.org>
runtime: document when cgo traceback function is called
Fixes #24518.
Change-Id: I99c79c5a2ab9dbe7f0d257c263da9d2b5d1d55c4
Reviewed-on: https://go-review.googlesource.com/121917 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Mark Fischer [Mon, 2 Jul 2018 04:56:46 +0000 (00:56 -0400)]
net/http: make Transport treat 101 as a terminal status
Before CL 116855, Transport would only skip over 100 (expect-continue)
responses automatically and treat all other 1xx responses as if they
were the final status. CL 116855 made the Transport more spec
compliant (ignoring unknown 1xx responses), but broke "101 Switching
Protocols" in the process. Since 101 is already in use and defined to
not have a following message, treat it as terminal.
Note that because the Client/Transport don't support hijacking the
underlying Conn, most clients doing a WebSocket or other protocol
upgrade are probably using net.Dial + http.ReadResponse instead, which
remained unaffected (before & after this CL).
The main affect of this CL is to fix tests that were using the
Client/Transport to test that a server returns 101, presumably without
actually switching to another protocol.
Michael Munday [Sat, 30 Jun 2018 09:14:49 +0000 (10:14 +0100)]
cmd/compile: keep autos whose address reaches a phi
If the address of an auto reaches a phi then any further stores to
the pointer represented by the phi probably need to be kept. This
is because stores to the other arguments to the phi may be visible
to the program.
Fixes #26153.
Change-Id: Ic506c6c543bf70d792e5b1a64bdde1e5fdf1126a
Reviewed-on: https://go-review.googlesource.com/121796
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
Peter Gonda [Wed, 24 Jan 2018 22:45:28 +0000 (14:45 -0800)]
cmd/cgo: permit missing dynamic symbol section
Allow static complication of cgo enabled libraries.
Fixes #16651
Change-Id: I0729ee4e6e5f9bd1cbdb1bc2dcbfe34463df547c
Reviewed-on: https://go-review.googlesource.com/89655
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Sun, 1 Jul 2018 21:18:03 +0000 (14:18 -0700)]
cmd/go: add -flat_namespace to LDFLAGS whitelist
Fixes #26173
Change-Id: I032551f63b359c8cbb7296931e1957d2bff8f328
Reviewed-on: https://go-review.googlesource.com/121819
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
cmd/vendor/golang.org/x/sys/unix: pick up fixes for TestUtimesNanoAt
TestUtimesNanoAt in the vendored copy of golang.org/x/sys/unix currently
fails on the linux-arm-arm5spacemonkey builder. Update the vendored copy
to pick up the fix from CL 120816.
Updates #26034
Change-Id: I75c8875089f58a4c32e2e7aa75884b2bcba7bd68
Reviewed-on: https://go-review.googlesource.com/121800
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Thu, 21 Jun 2018 16:08:36 +0000 (12:08 -0400)]
runtime: query thread stack size from OS on Windows
Currently, on Windows, the thread stack size is set or assumed in many
different places. In non-cgo binaries, both the Go linker and the
runtime have a copy of the stack size, the Go linker sets the size of
the main thread stack, and the runtime sets the size of other thread
stacks. In cgo binaries, the external linker sets the main thread
stack size, the runtime assumes the size of the main thread stack will
be the same as used by the Go linker, and the cgo entry code assumes
the same.
Furthermore, users can change the main thread stack size using
editbin, so the runtime doesn't even really know what size it is, and
user C code can create threads with unknown thread stack sizes, which
we also assume have the same default stack size.
This is all a mess.
Fix the corner cases of this and the duplication of knowledge between
the linker and the runtime by querying the OS for the stack bounds
during thread setup. Furthermore, we unify all of this into just
runtime.minit for both cgo and non-cgo binaries and for the main
thread, other runtime-created threads, and C-created threads.
Updates #20975.
Change-Id: I45dbee2b5ea2ae721a85a27680737ff046f9d464
Reviewed-on: https://go-review.googlesource.com/120336
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Wed, 20 Jun 2018 20:25:41 +0000 (16:25 -0400)]
runtime: initialize g0 stack bounds on Windows to full stack
Currently, we allocate 1MB or 2MB thread stacks on Windows, but in
non-cgo binaries still set the g0 stack bounds assuming only 64k is
available. While this is fine in pure Go binaries, a non-cgo Go binary
on Windows can use the syscall package to call arbitrary DLLs, which
may call back into Go. If a DLL function uses more than 64k of stack
and then calls back into Go, the Go runtime will believe that it's out
of stack space and crash.
Fix this by plumbing the correct stack size into the g0 stacks of
non-cgo binaries. Cgo binaries already use the correct size because
their g0 stack sizes are set by a different code path.
Fixes #20975.
Change-Id: Id6fb559cfe1e1ea0dfac56d4654865c20dccf68d
Reviewed-on: https://go-review.googlesource.com/120195
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Jakub Čajka [Mon, 25 Jun 2018 10:31:53 +0000 (12:31 +0200)]
cmd/go: call flag.Parse to properly initialize test environment variables
Executing tests in cmd/go/internal/modfetch/gitrepo/fetch_test.go in enviroment
witout outside connectivity in to the internet results in tests failure:
2018/06/25 12:48:26 git clone --mirror https://vcs-test.golang.org/git/gitrepo1 /tmp/gitrepo-test-221822392/gitrepo2 in : exit status 128:
Cloning into bare repository '/tmp/gitrepo-test-221822392/gitrepo2'...
fatal: unable to access 'https://vcs-test.golang.org/git/gitrepo1/': Could not resolve host: vcs-test.golang.org
FAIL cmd/go/internal/modfetch/gitrepo 0.144s
Call flag.Parse in TestMain to properly initialize test environment variables
Fixes #26007
Change-Id: I059e27db69c0ca0e01db724035a25d6fefb094b5
Reviewed-on: https://go-review.googlesource.com/120735
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Cherry Zhang [Sat, 30 Jun 2018 03:09:34 +0000 (23:09 -0400)]
misc/wasm: make sure value ref id is unique
For each Javascript object that returns to Go as a js.Value, we
associate the ref id to it. But if this ref id is copied or
inherited to other object, it would mess up the ref-object
mapping.
In storeValue, make sure the object is indeed the one we are
storing. Otherwise allocate a new ref id.
Rob Pike [Sat, 30 Jun 2018 22:03:36 +0000 (08:03 +1000)]
testing/cover: improve comments on CoverBlock
The previous CL (https://go-review.googlesource.com/c/go/+/96756)
added comments that didn't really say much, but there is something
so say: what the units are and that they are indexed starting at 1.
Add a more helpful comment on the type, and also follow proper
style by using initial capitals and a period.
Change-Id: Id19cd5f392faf7c7bac034073f276cc770589075
Reviewed-on: https://go-review.googlesource.com/121875 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Myasoedov [Sat, 18 Nov 2017 17:49:54 +0000 (12:49 -0500)]
regexp: examples for Regexp.FindIndex and Regexp.FindAllSubmatchIndex methods
This commit adds examples that demonstrate usage in a practical way.
Change-Id: I105baf610764c14a2c247cfc0b0c06f27888d377
Reviewed-on: https://go-review.googlesource.com/78635 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Tue, 26 Jun 2018 21:40:51 +0000 (14:40 -0700)]
cmd/cgo: handle GCC 8 change in errors about constant initializers
Before GCC 8 C code like
const unsigned long long int neg = (const unsigned long long) -1;
void f(void) { static const double x = (neg); }
would get an error "initializer element is not constant". In GCC 8 and
later it does not.
Because a value like neg, above, can not be used as a general integer
constant, this causes cgo to conclude that it is a floating point
constant. The way that cgo handles floating point values then causes
it to get the wrong value for it: 18446744073709551615 rather than -1.
These are of course the same value when converted to int64, but Go
does not permit that kind of conversion for an out-of-range constant.
This CL side-steps the problem by treating floating point constants
with integer type as they would up being treated before GCC 8: as
variables rather than constants.
Fixes #26066
Change-Id: I6f2f9ac2fa8a4b8218481b474f0b539758eb3b79
Reviewed-on: https://go-review.googlesource.com/121035
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Brad Fitzpatrick [Wed, 20 Jun 2018 19:36:14 +0000 (19:36 +0000)]
time: clarify Unix, UnixNano, and In a bit
Fixes #23316
Change-Id: Ia1758b406d369bbfaace0bdfea02cd6f40735b65
Reviewed-on: https://go-review.googlesource.com/120060 Reviewed-by: Ian Lance Taylor <iant@golang.org>
http2: make Server send GOAWAY if Handler sets "Connection: close" header
https://golang.org/cl/121415
Fixes #20977
Change-Id: I9b8659b5191409ed007e2d911913763bcbabb7cc
Reviewed-on: https://go-review.googlesource.com/121695 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Thu, 28 Jun 2018 23:45:28 +0000 (16:45 -0700)]
runtime: throw if the runtime panics with out of bounds index
If the runtime code panics due to a bad index or slice expression,
then throw instead of panicing. This will skip calls to recover and dump
the entire runtime stack trace. The runtime should never panic due to
an out of bounds index, and this will help with debugging if it does.
Austin Clements [Fri, 29 Jun 2018 18:56:48 +0000 (14:56 -0400)]
runtime: remap stack spans with MAP_STACK on OpenBSD
OpenBSD 6.4 is going to start requiring that the SP points to memory
that was mapped with MAP_STACK on system call entry, traps, and when
switching to the alternate signal stack [1]. Currently, Go doesn't map
any memory MAP_STACK, so the kernel quickly kills Go processes.
Fix this by remapping the memory that backs stack spans with
MAP_STACK, and re-remapping it without MAP_STACK when it's returned to
the heap.
Daniel Martí [Fri, 29 Jun 2018 15:59:04 +0000 (16:59 +0100)]
os: treat "${}" in Expand like in Go 1.10
CL 103055 made it so that invalid parameter expansions, like "$|", did
not make the dollar sign silently disappear.
A few edge cases were not taken into account, such as "${}" and "${",
which were now printing just "$". For consistency and to not break
existing programs, go back to eating up the characters when invalid
syntax is encountered.
For completeness, add a "$" test case too, even though its behavior is
unchanged by this CL.
Fixes #26135.
Change-Id: I5d25db9a8356dc6047a8502e318355113a99b247
Reviewed-on: https://go-review.googlesource.com/121636
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
bill_ofarrell [Thu, 28 Jun 2018 22:39:37 +0000 (18:39 -0400)]
bytes, strings: fix comparison of long byte slices on s390x
The existing implementation of bytes.Compare on s390x doesn't work properly for slices longer
than 256 elements. This change fixes that. Added tests for long strings and slices of bytes.
Brad Fitzpatrick [Fri, 29 Jun 2018 15:00:52 +0000 (15:00 +0000)]
net/http: update docs on Transport.DisableKeepAlives
Be super explicit that HTTP keep-alives != TCP keep-alives.
Fixes #26128
Change-Id: I77d74a6fe077259d996543f901a58aa3e49c1093
Reviewed-on: https://go-review.googlesource.com/121616 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Daniel Martí [Fri, 29 Jun 2018 16:46:17 +0000 (17:46 +0100)]
strings: add note for new Go developers to TrimLeft and TrimRight
If one quickly looks at the strings package godoc, reading the name
TrimLeft, one might think it removes a prefix from the string.
The function's godoc does explain its purpose, but it's apparent that it
is not clear enough, as there have been numerous raised issues about
this confusion: #12771 #14657 #18160 #19371 #20085 #25328 #26119. These
questions are also frequent elsewhere on the internet.
Add a very short paragraph to the godoc, to hopefully point new Go
developers in the right direction faster. Do the same thing for
TrimRight and TrimSuffix.
David Chase [Thu, 28 Jun 2018 20:22:21 +0000 (16:22 -0400)]
cmd/compile: make OpAddr depend on VarDef in storeOrder
Given a carefully constructed input, writebarrier would
split a block with the OpAddr in the first half and the
VarDef in the second half which ultimately leads to a
compiler crash because the scheduler is no longer able
to put them in the proper order.
To fix, recognize the implicit dependence of OpAddr on
the VarDef of the same symbol if any exists.
This fix was chosen over making OpAddr take a memory
operand to make the dependence explicit, because this
change is less invasive at this late part of the 1.11
release cycle.
Cherry Zhang [Fri, 29 Jun 2018 00:34:05 +0000 (20:34 -0400)]
cmd/compile: check SSAability in handling of INDEX of 1-element array
SSA can handle 1-element array, but only when the element type
is SSAable. When building SSA for INDEX of 1-element array, we
did not check the element type is SSAable. And when it's not,
it resulted in an unhandled SSA op.
Daniel Martí [Thu, 28 Jun 2018 16:18:01 +0000 (17:18 +0100)]
cmd/vet: don't run buildtag check when in vetxonly mode
The check was running in the loop that read source files in, much before
any of the other checks ran. Vetxonly makes vet exit early, but after
all the source files have been read.
To fix this, simply run the buildtag check along with all the other
checks that get run on specific syntax tree nodes.
Add a cmd/go test with go test -a, to ensure that the issue as reported
is fixed.
Fixes #26102.
Change-Id: If6e3b9418ffa8166c0f982668b0d10872283776a
Reviewed-on: https://go-review.googlesource.com/121395
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Thu, 28 Jun 2018 22:44:41 +0000 (15:44 -0700)]
reflect: remove struct tags from unexported types
Before CL 4281055 in 2011, the reflect package was quite different.
rtype, then called commonType, was embedded in exported structs with
names like StructType. In order to avoid accidental conversions
between pointers to these public structs, which sometimes had
identical fields, the embedded commonType fields were tagged.
In CL 4281055 the formerly public structs were unexported, and all
access was done through the Type interface. At that point the field
tags in the reflect structs were no longer useful.
In Go 1.8 the language was changed to ignore struct field tags when
converting between types. This made the field tags in the reflect
structs doubly useless.
This CL simply removes them.
Fixes #20914
Change-Id: I9af4d6d0709276a91a6b6ee5323cad9dcd0cd0a0
Reviewed-on: https://go-review.googlesource.com/121475
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Brad Fitzpatrick [Thu, 28 Jun 2018 21:01:45 +0000 (21:01 +0000)]
net/http: make Server.Shutdown treat new connections as idle after 5 seconds
The Server distinguishes "new" vs "idle" connections. A TCP connection
from which no bytes have yet been written is "new". A connection that
has previously served a request and is in "keep-alive" state while
waiting for a second or further request is "idle".
The graceful Server.Shutdown historically only shut down "idle"
connections, with the assumption that a "new" connection was about to
read its request and would then shut down on its own afterwards.
But apparently some clients spin up connections and don't end up using
them, so we have something that's "new" to us, but browsers or other
clients are treating as "idle" to them.
This CL tweaks our heuristic to treat a StateNew connection as
StateIdle if it's been stuck in StateNew for over 5 seconds.
Fixes #22682
Change-Id: I01ba59a6ab67755ca5ab567041b1f54aa7b7da6f
Reviewed-on: https://go-review.googlesource.com/121419
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Russ Cox [Thu, 28 Jun 2018 04:05:46 +0000 (00:05 -0400)]
cmd/vet: fix ironic misuse of fmt.Sprintf
Move badf helper into top-level function so that prints from buildtag.go
are once again themselves printf-format-checked by vet.
Also, fix implementation, which was missing a ... in the Sprintf call and
produced messages like:
/Users/rsc/x_test.go:1: +build comment must appear before package clause and be followed by a blank line%!(EXTRA []interface {}=[])
Dmitri Shuralyov [Wed, 27 Jun 2018 19:37:19 +0000 (15:37 -0400)]
internal/syscall/unix: add build constraint to nonblocking_js.go
The intention was for this file to be constrained to both js and wasm,
but the build constraint was missing, causing it to be constrained only
to js because of the _js suffix in the filename.
Add a js,wasm build constraint. The js part is redundant, but specified
anyway to make it more visible and consistent with other similar files.
This issue was spotted while working on GopherJS, because it was causing
a conflict there (both nonblocking.go and nonblocking_js.go files were
being matched).