The docs were too specific. Make it vaguer. There are conditions for
which the Transport will try to reuse a connection anyway, even if the
Response Body isn't read to EOF or closed, but we don't need to get
into all the details in the docs.
Fixes#22954
Change-Id: I3b8ae32aeb1a61b396d0026e129552afbfecceec
Reviewed-on: https://go-review.googlesource.com/86276
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 84735 strengthened the -x test to make sure commands succeed,
using set -e, but the gcc flag tests can fail. Change them to say || true.
Fixes#23337.
Change-Id: I01e4017cb36ceb147b56935c2636de52ce7bdfdb
Reviewed-on: https://go-review.googlesource.com/86239
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.
fixes#8549
Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7
Reviewed-on: https://go-review.googlesource.com/86115
Reviewed-by: Adam Langley <agl@golang.org>
In the comment of seedPost, the word: condiiton was changed to: condition
Change-Id: I8967cc0e9f5d37776bada96cc1443c8bf46e1117
Reviewed-on: https://go-review.googlesource.com/86156
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The spec refers to a map's key and element types; thus the respective
values are "keys" and "elements". Also, a map value is the value of
the entire map.
Similar fix for channels, where appropriate.
Fixes#23254.
Change-Id: I6f03ea6d86586c7b0b3e84f0c2e9446b8109fa53
Reviewed-on: https://go-review.googlesource.com/85999
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
If test case framing appears in ordinary test output,
then test2json can get confused. If the fake framing is being
saved with t.Logf/t.Errorf/etc then we can already
distinguish it from real framing, and the code did.
It just forgot to write that framing as output (1-line fix).
If the fake framing is being generated by printing directly
to stdout/stderr, then test2json will simply get confused.
There's not a lot to do at that point (maybe it's even a feature).
Fixes#23036.
Change-Id: I29449c7ace304172b89d8babe23de507c0500455
Reviewed-on: https://go-review.googlesource.com/86238
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go test -json was inadvertently disabling caching. Fix that.
Fixes#22984.
Change-Id: Ic933a8c8ac00ce8253e934766954b1ccc6ac0cec
Reviewed-on: https://go-review.googlesource.com/84075
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If you have a package p1 with an xtest (package p1_test)
that imports p2, where p2 itself imports p1, then when
trying to do coverage for p1 we need to make sure to
recompile p2. The problem was that the overall package
import graph looked like:
main -> p1_test -> p2 -> p1
Since we were recompiling p1 with coverage, we correctly
figured out that because p2 depends on a package being
recompiled due to coverage, p2 also needs to be split (forked) to
insert the dependency on the modified p1. But then we used
the same logic to split p1_test and main, with the effect that
the changes to p2 and p1_test and main were lost, since the
caller was still holding on to the original main, not the split version.
Change the code to treat main and p1_test as "already split"
and just update them in place.
Fixes#23314.
Change-Id: If7edeca6e39cdaeb5b9380d00b0c7d8c5891f086
Reviewed-on: https://go-review.googlesource.com/86237
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
findrunnable loops over allp to check run queues *after* it has
dropped its own P. This is unsafe because allp can change when nothing
is blocking safe-points. Hence, procresize could change allp
concurrently with findrunnable's loop. Beyond generally violating Go's
memory model, in the best case this could findrunnable to observe a
nil P pointer if allp has been grown but the new slots not yet
initialized. In the worst case, the reads of allp could tear, causing
findrunnable to read a word that isn't even a valid *P pointer.
Fix this by taking a snapshot of the allp slice header (but not the
backing store) before findrunnable drops its P and iterating over this
snapshot. The actual contents of allp are immutable up to len(allp),
so this fixes the race.
Updates #23098 (may fix).
Change-Id: I556ae2dbfffe9fe4a1bf43126e930b9e5c240ea8
Reviewed-on: https://go-review.googlesource.com/86215
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Update rewrite algorithm by coping code from
go/internal/work/buildid:updateBuildID.
Probably, this is not the best option. We could provide high-level API
in cmd/internal/buildid in the future.
Fixes#23181
Change-Id: I336a7c50426ab39bc9998b55c372af61a4fb21a7
Reviewed-on: https://go-review.googlesource.com/84735
Reviewed-by: Russ Cox <rsc@golang.org>
After 1.10, gcflags apply to only the immediate target.
Change-Id: I3bf331c76041e7b533076cb2f3274e44aafff58a
Reviewed-on: https://go-review.googlesource.com/84775
Reviewed-by: Heschi Kreinick <heschi@google.com>
In func TestXxxx(*testing.T) the Xxxx can be anything that can appear
in an identifier, but can't start with a lowercase letter. Clarify the docs.
Fixes#23322
Change-Id: I5c297916981f7e3890ee955d12bc7422a75488e2
Reviewed-on: https://go-review.googlesource.com/86001
Reviewed-by: Rob Pike <r@golang.org>
CL 78735 description:
time: add space padding layout strings(using underscore) for not only day but others
As mentioned in #22802, only day component of layout string has space
padding(represented by one underscore before its placeholder). This
commit expands the rule for month, hour, minute and second.
Updates #22802 (maybe fixes it)
Revert this CL because it breaks currently working formats that happen
to use underscores.
Fixes#23259
Change-Id: I64acaaca9b5b74785ee0f0be7910574e87daa649
Reviewed-on: https://go-review.googlesource.com/85998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
I don't know why these errors occur. Ignore them to avoid breaking the
build.
Updates #22019
Change-Id: Ia048e6d9b928e8e237b311ff3a364e7a23af4aa4
Reviewed-on: https://go-review.googlesource.com/86000
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We retrieve an error using getsockopt with SO_ERROR. We were reporting
the error as coming from "getsockopt", but really it is coming from
"connect". It is not getsockopt that failed.
Fixes#19302
Change-Id: I510ab76e4b04c70cd9dfdfc46d9a410bf653d017
Reviewed-on: https://go-review.googlesource.com/85997
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Commit c2c07c7989 (CL 49331) changed the linker and runtime to always
use 2MB stacks on 64-bit Windows. This is the corresponding change to
make 32-bit Windows always use large (1MB) stacks because it's
difficult to detect when Windows applications will call into arbitrary
C code that may expect a large stack.
This is done as a separate change because it's possible this will
cause too much address space pressure for a 32-bit address space. On
the other hand, cgo binaries on Windows already use 1MB stacks and
there haven't been complaints.
Updates #20975.
Change-Id: I8ce583f07cb52254fb4bd47250f1ef2b789bc490
Reviewed-on: https://go-review.googlesource.com/49610
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
During the refactor in 1126d1483f I
introduced a logical error within one withLock function that used
the result of the call before checking for the error. Change
the order so that the error is checked before the result is used.
None of the other withLock uses have similar issues.
Fixes#23208
Change-Id: I6c5dcf262e36bad4369c850f1e0131066360a82e
Reviewed-on: https://go-review.googlesource.com/85175
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Caleb Spare <cespare@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A Select Op could produce a value with upper 32 bits NOT zeroed,
for example, Div32 is lowered to (Select0 (DIVL x y)).
In theory, we could look into the argument of a Select to decide
whether the upper bits are zeroed. As it is late in release cycle,
just disable this optimization for Select for now.
Fixes#23305.
Change-Id: Icf665a2af9ccb0a7ba0ae00c683c9e349638bf85
Reviewed-on: https://go-review.googlesource.com/85736
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Modify the regex in TestLinuxSendfile to not match the parameters of
the syscall, just its name and the opening parenthesis. This is enough
to recognize that the syscall was invoked.
This fixes the TestLinuxSendfile test when running in Clear Linux,
where strace always execute with -yy implied, having output with extra
information in the parameters:
[pid 5336] sendfile(6<TCP:[127.0.0.1:35007->127.0.0.1:55170]>, 8</home/c/src/go/src/net/http/testdata/index.html>, NULL, 22) = 22
Change-Id: If7639b785d5fdf65fae8e6149a97a57b06ea981c
Reviewed-on: https://go-review.googlesource.com/85657
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#23224
The previous Pow code had an optimization for
powers equal to ±0.5 that used Sqrt for
increased accuracy/speed. This caused special
cases involving powers of ±0.5 to disagree with
the Pow spec. This change places the Sqrt optimization
after all of the special case handling.
Change-Id: I6bf757f6248256b29cc21725a84e27705d855369
Reviewed-on: https://go-review.googlesource.com/85660
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
this solution as it stands doesn't work with
non-english device names (golang/go#23191 (which has a fix))
and names some devices differently (golang/go#23153) probably due to the
fact that this test previously only ran on Server 2008.
Re-opens golang/go#20073
Change-Id: I5c36774ddd85ac07620b4015372d564acbb169ad
Reviewed-on: https://go-review.googlesource.com/85315
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Refactoring to make it slightly easier to add tests,
easier to add variable-printing-support for Delve,
and made naming and tagging more consistent.
No changes to the content of the test itself or when it is
run.
Change-Id: I374815b65a203bd43b27edebd90b859466d1c33b
Reviewed-on: https://go-review.googlesource.com/84979
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
golang.org/cl/81315 attempted to distinguish system goroutines
by examining the function name in the goroutine stack. It assumes that
the information would be available when GoSysBlock or GoInSyscall
events are processed, but it turned out the stack information is
set too late (when the goroutine gets a chance to run).
This change initializes the goroutine information entry when
processing GoCreate event which should be one of the very first
events for the every goroutine in trace.
Fixes#22574
Change-Id: I1ed37087ce2e78ed27c9b419b7d942eb4140cc69
Reviewed-on: https://go-review.googlesource.com/83595
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
My previous fix for issue 23179 was incomplete; it turns out that if
an unnamed parameter is below a specific size threshold, it gets
register-promoted away by the compiler (hence not encountered during
some parts of DWARF inline info processing), but if it is sufficiently
large, it is allocated to the stack as a named variable and treated as
a regular parameter by DWARF generation. Interestingly, something in
the ppc64le build of k8s causes an unnamed parameter to be retained
(where on amd64 it is deleted), meaning that this wasn't caught in my
amd64 testing.
The fix is to insure that "_" params are treated in the same way that
"~r%d" return temps are when matching up post-optimization inlined
routine params with pre-inlining declarations. I've also updated the
test case to include a "_" parameter with a very large size, which
also triggers the bug on amd64.
Fixes#23179.
Change-Id: I961c84cc7a873ad3f8f91db098a5e13896c4856e
Reviewed-on: https://go-review.googlesource.com/84975
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The current implementation prints a log, "invalid program: unexpected
type for embedded field", when the form *package.ident is embedded in
a struct declaration.
Note that since valid qualified identifiers must be exported, the result
for a valid program does not change.
Change-Id: If8b9d7056c56b6a6c5482eb749168a63c65ef685
Reviewed-on: https://go-review.googlesource.com/84436
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The helper routine for returning pre-inlining parameter declarations
wasn't properly handling the case where you have more than one
parameter named "_" in a function signature; this triggered a map
collision later on when the function was inlined and DWARF was
generated for the inlined routine instance.
Fixes#23179.
Change-Id: I12e5d6556ec5ce08e982a6b53666a4dcc1d22201
Reviewed-on: https://go-review.googlesource.com/84755
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The driver.Value type may be more then the documented 6 types if the
database driver supports it. Document that fact.
Updates #23077
Change-Id: If7e2112fa61a8cc4e155bb31e94e89b20c607242
Reviewed-on: https://go-review.googlesource.com/84636
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Disable the three linker DWARF tests that invoke the compiler in
non-debug mode on Solaris, since this seems to trigger a split stack
overflow. These can be turned back on once the issue in question is
resolved.
Updates #23168.
Change-Id: I5be1b098e33e8bad3bc234a0964eab1dee7e7954
Reviewed-on: https://go-review.googlesource.com/84655
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Rename -list flag to -errlist to avoid confusion with the go
test flag -list (introduced later).
This flag is only needed to get an error list when running the
go/types test harness manually on select files, e.g., as in:
go test -run=Check -files=x.go -errlist
Change-Id: I67febcf968d2d8f4ff00c81eea7b2df723560eac
Reviewed-on: https://go-review.googlesource.com/84378
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Exercise of preparing a how-to document motivated me to
clean up some of the stupider wonkier bits. Since this
does not run for test -short, expect no change for trybots,
did pass testing with OSX gdb and a refreshed copy of Delve.
Change-Id: I58edd10599b172c4787ff5f110db078f6c2c81c5
Reviewed-on: https://go-review.googlesource.com/83957
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Location lists are only supported on x86 and amd64, so the
test expecting them failed everywhere else. Make that test
skip unless GOARCH is x86 or amd64.
Change-Id: Id86b34d30c6a0b97e6fa0cd5aca31f51ed84f556
Reviewed-on: https://go-review.googlesource.com/84395
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
