- 03 Jul, 2018 4 commits
-
-
Nikhil Benesch authored
Fixes #24518. Change-Id: I99c79c5a2ab9dbe7f0d257c263da9d2b5d1d55c4 Reviewed-on: https://go-review.googlesource.com/121917Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mark Fischer authored
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. Fixes #26161 Change-Id: Ie3cd3a465f948c4d6f7ddf2a6a78a7fb935d0672 Reviewed-on: https://go-review.googlesource.com/121860Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #20239 Change-Id: Icb021daad82e6905f536e4ef09ab219500b08167 Reviewed-on: https://go-review.googlesource.com/81778 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
The vetx output file is a build output, and as such should be deterministic. This CL changes it to not depend on map iteration order. This avoids a pointless GODEBUG=gocacheverify=1 failure. Updates #25666 Change-Id: Ic132bad134cb10938275f883c2c68432cb7c4409 Reviewed-on: https://go-review.googlesource.com/121941 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
- 02 Jul, 2018 12 commits
-
-
Cherry Zhang authored
Late opt pass may generate dead stores, which messes up store chain calculation in later passes. Run generic deadcode even in -N mode to remove them. Fixes #26163. Change-Id: I8276101717bb978d5980e6c7998f53fd8d0ae10f Reviewed-on: https://go-review.googlesource.com/121856 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
These rules don't even type check. ADDQconstmodify returns memory, and it is being rewritten to a value that returns an int64. There should be a MOVQstore wrapped around the result. These rules never fire during all.bash, so they aren't even tested. I'm just going to remove them for now. Change-Id: I76008eb51ae4e16c707fac73c05a8d67cac149ae Reviewed-on: https://go-review.googlesource.com/121935 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Munday authored
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 authored
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 authored
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>
-
Tobias Klauser authored
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 authored
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 authored
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 authored
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>
-
Austin Clements authored
The OpenBSD sysctl code has been copy-pasted three times now. Abstract it. Change-Id: Ia5558927f0bc2b218b5af425dab368b5485d266c Reviewed-on: https://go-review.googlesource.com/121775 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Ian Lance Taylor authored
On the OpenBSD builder this reduces the test time from 213 seconds to 60 seconds, without loss of testing. Not sure why the test is so much slower on OpenBSD, so not closing the issues. Updates #26155 Updates #26174 Change-Id: I13b58bbe3b209e591c308765077d2342943a3d2a Reviewed-on: https://go-review.googlesource.com/121820 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ralph Corderoy <ralph@inputplus.co.uk> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
cch123 authored
Change-Id: Idbd8a1b5bfeb1c23c86cef0697cf0380900e95f3 GitHub-Last-Rev: a8c2b27046582c4eef932a8502826a3b23b8dab3 GitHub-Pull-Request: golang/go#26175 Reviewed-on: https://go-review.googlesource.com/121821Reviewed-by: Keith Randall <khr@golang.org>
-
- 01 Jul, 2018 2 commits
-
-
Cherry Zhang authored
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. Fixes #26143. Change-Id: Ie60bb2f8d1533da1bbe6f46045866515ec2af5a9 Reviewed-on: https://go-review.googlesource.com/121835 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Richard Musiol <neelance@gmail.com>
-
Rob Pike authored
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/121875Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 30 Jun, 2018 1 commit
-
-
Alex Myasoedov authored
This commit adds examples that demonstrate usage in a practical way. Change-Id: I105baf610764c14a2c247cfc0b0c06f27888d377 Reviewed-on: https://go-review.googlesource.com/78635Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 29 Jun, 2018 16 commits
-
-
Ian Lance Taylor authored
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>
-
Caleb Martinez authored
Fixes issue #26139 Change-Id: Id9a3e5c443ee175ad9add6296ed45bdf328b15a0 GitHub-Last-Rev: b3f8a8f165d15cfffd4948151eae34f95330748c GitHub-Pull-Request: golang/go#26146 Reviewed-on: https://go-review.googlesource.com/121696Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #23316 Change-Id: Ia1758b406d369bbfaace0bdfea02cd6f40735b65 Reviewed-on: https://go-review.googlesource.com/120060Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Updates http2 to x/net/http2 git rev 97aa3a539 for: http2: dynamic table updates must occur first https://golang.org/cl/111681 http2: receiving too much data is a protocol error https://golang.org/cl/111679 http2: correct overflow protection https://golang.org/cl/111675 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/121695Reviewed-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 authored
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. For #24991 Updates #25201 Change-Id: I85a9feded8f0de914ee1558425931853223c0514 Reviewed-on: https://go-review.googlesource.com/121515Reviewed-by: Austin Clements <austin@google.com>
-
Austin Clements authored
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. [1] http://openbsd-archive.7691.n7.nabble.com/stack-register-checking-td338238.html Fixes #26142. Change-Id: I656eb84385a22833445d49328bb304f8cdd0e225 Reviewed-on: https://go-review.googlesource.com/121657 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Daniel Martí authored
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 authored
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. Fixes #26114 Change-Id: If6d8b68ee6dbcf99a24f867a1d3438b1f208954f Reviewed-on: https://go-review.googlesource.com/121495Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Chase authored
This reverts commit 1a27f048. Reason for revert: Broke the ssacheck and -N-l builders, and the -N-l fix looks like it will take some time and take a different route entirely. Change-Id: Ie0ac5e86ab7d72a303dfbbc48dfdf1e092d4f61a Reviewed-on: https://go-review.googlesource.com/121715Reviewed-by: David Chase <drchase@google.com>
-
Brad Fitzpatrick authored
Be super explicit that HTTP keep-alives != TCP keep-alives. Fixes #26128 Change-Id: I77d74a6fe077259d996543f901a58aa3e49c1093 Reviewed-on: https://go-review.googlesource.com/121616Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
I thought I removed this but failed to amend it to my commit before submitting. Change-Id: I2d687d91f4de72251548faa700006af0fea503af Reviewed-on: https://go-review.googlesource.com/121615 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
-
Daniel Martí authored
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. Change-Id: I4dee5ed8dd9fba565b4755bad12ae1ee6d277959 Reviewed-on: https://go-review.googlesource.com/121637Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Stephen L authored
Fill in the missing descriptions for the CoverBlock struct fields Change-Id: I9257881a19b01e5cfe61cf19a91375b6d7cc68ef GitHub-Last-Rev: f5b9e1d49d1c00f59ce4d3684915e5e93ec0297a GitHub-Pull-Request: golang/go#24079 Reviewed-on: https://go-review.googlesource.com/96756Reviewed-by: Andrew Bonventre <andybons@golang.org> Run-TryBot: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Chase authored
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. Fixes #26105. Change-Id: I9b65460673af3af41740ef877d2fca91acd336bc Reviewed-on: https://go-review.googlesource.com/121436 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Cherry Zhang authored
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. Fixes #26120. Change-Id: Id709996b5d9d90212f6c56d3f27eed320a4d8360 Reviewed-on: https://go-review.googlesource.com/121496 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Daniel Martí authored
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>
-
- 28 Jun, 2018 5 commits
-
-
Ian Lance Taylor authored
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>
-
Robert Griesemer authored
Fixes #24763. Change-Id: Ibe534271d75b6961d00ebfd7d42c43a3ac650d79 Reviewed-on: https://go-review.googlesource.com/121335Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Brad Fitzpatrick authored
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 authored
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 {}=[]) These were introduced in CL 111415. Change-Id: I000af3a4e01dc99fc79c9146aa68a71dace1460f Reviewed-on: https://go-review.googlesource.com/121300 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Andrew Braunstein authored
Fix a comment that misrepresented the Assign operator (=). Rename: colon-equals -> equals. Change-Id: I405b8acfb0bcd1b176a91a95f9bfb61a4e85815f GitHub-Last-Rev: aec0bf594c63d7b015f88f97f9953ade976817a4 GitHub-Pull-Request: golang/go#26112 Reviewed-on: https://go-review.googlesource.com/121416Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-