- 09 Jul, 2018 13 commits
-
-
Keith Randall authored
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>
-
Brad Fitzpatrick authored
Added since last update. Change-Id: Ic5be0e2e379d422ef72b956a794d65613a0dd7be Reviewed-on: https://go-review.googlesource.com/122815Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
Ian Lance Taylor authored
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>
-
Josh Bleecher Snyder authored
CL 121916 showed that sym.Symbol matters for linker performance. Prevent accidental regression. Change-Id: I5fd998c91fdeef9e721bc3f6e30f775b81103e95 Reviewed-on: https://go-review.googlesource.com/122716 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Stephan Renatus authored
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. Spec: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00 Fixes #15867 Based on https://github.com/reedloden/go/commit/eb31a0f063c80058bbb3abff4ca09b3565985500 by Reed Loden <reed@hackerone.com> Change-Id: I98c8a9a92358b2f632990576879759e3aff38cff Reviewed-on: https://go-review.googlesource.com/79919 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
This updates x/net/http/httpproxy to git rev c21de06a for: http/httpproxy: support CIDR notation and ports with NO_PROXY https://golang.org/cl/115255 Fixes #16704 Change-Id: Ic96a0a36828779f88e68cd715bd076f36fd45e7a Reviewed-on: https://go-review.googlesource.com/122655 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Fraenkel <michael.fraenkel@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #24201 Change-Id: Ib970c4eeaa90489d014482276a7e5afa94a50741 Reviewed-on: https://go-review.googlesource.com/122675Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Mark Fischer authored
Add field to http.Transport which limits connections per host, including dial-in-progress, in-use and idle (keep-alive) connections. For HTTP/2, this field only controls the number of dials in progress. Fixes #13957 Change-Id: I7a5e045b4d4793c6b5b1a7191e1342cd7df78e6c Reviewed-on: https://go-review.googlesource.com/71272Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
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. Fixes #26116 Change-Id: I14230ee8126054b750e2a1f2b18eb8f09873dbd5 Reviewed-on: https://go-review.googlesource.com/121940 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Heschi Kreinick <heschi@google.com>
-
Ian Lance Taylor authored
Fixes #22696 Change-Id: Ibe4628f71d64a2b36b655ea69710a925924b12a3 Reviewed-on: https://go-review.googlesource.com/122586 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
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. Fixes #26219. Change-Id: Ie632e709eb3caf489d85efceac0e4b130ec2019f Reviewed-on: https://go-review.googlesource.com/122596 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Original CL description: When using test -cover or -coverprofile the output for "no test files" is the same format as for "no tests to run". Reverting because this CL changed cmd/go to build test binaries for packages that have no tests, leading to extra work and confusion. Updates #24570 Fixes #25789 Fixes #26157 Fixes #26242 Change-Id: Ibab1307d39dfaec0de9359d6d96706e3910c8efd Reviewed-on: https://go-review.googlesource.com/122518 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Updates #19381 Change-Id: I62b8b0cd7170941af77281eb3aada3802623ec27 Reviewed-on: https://go-review.googlesource.com/122587Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 08 Jul, 2018 3 commits
-
-
Austin Clements authored
This test is skipped on Linux and should be skipped on Android for the same reason. Change-Id: I753c4788d935bd58874554b455c0d5be2315b794 Reviewed-on: https://go-review.googlesource.com/122585 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
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. Change-Id: I1065341180ab5ab4da63b406c641dcde93c9490b Reviewed-on: https://go-review.googlesource.com/122580 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
Since CL 122515, TestAbort is failing on Plan 9 because there is no SIGTRAP signal on Plan 9, but a note containing the "sys: breakpoint" string. This change fixes the TestAbort test by handling the Plan 9 case. Fixes #26265. Change-Id: I2fae00130bcee1cf946d8cc9d147a77f951be390 Reviewed-on: https://go-review.googlesource.com/122464 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
- 07 Jul, 2018 4 commits
-
-
Austin Clements authored
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>
-
Austin Clements authored
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>
-
Austin Clements authored
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>
-
Ben Shi authored
The ADDLmodify/SUBLmodify/ANDLmodify/ORLmodify/XORLmodify should have clobberFlags set to true. Change-Id: Ie447d536db51334eddc70c00a722647282186a69 Reviewed-on: https://go-review.googlesource.com/122556 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
- 06 Jul, 2018 11 commits
-
-
Ian Lance Taylor authored
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 authored
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. Fixes #25055. Change-Id: I6fd2756de2c7d5dbc33056f70b3028ca3aebab41 Reviewed-on: https://go-review.googlesource.com/122517 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #25517. Change-Id: I801eebe17eaed9be09f290e8f219a808dc98f837 Reviewed-on: https://go-review.googlesource.com/122408Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
Russ Cox authored
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 Change-Id: I6d59c40a1269f01cef62a3fb17b909571c2f2adb Reviewed-on: https://go-review.googlesource.com/122407 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
Brad Fitzpatrick authored
Change-Id: Ie801fe6a2883d79229ee2955e26948c1b4964802 Reviewed-on: https://go-review.googlesource.com/122496Reviewed-by:
Russ Cox <rsc@golang.org>
-
David du Colombier authored
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 authored
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>
-
Michael Munday authored
I don't have access to this e-mail inbox anymore. Change-Id: Ia3dff6a56c7f6c782be74a998a622ef0611eca7e Reviewed-on: https://go-review.googlesource.com/122456Reviewed-by:
Daniel Martí <mvdan@mvdan.cc>
-
Daniel Martí authored
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 Fixes #26233. Change-Id: I819d7eedb67c48839313427675facb39d9c17257 Reviewed-on: https://go-review.googlesource.com/122355 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Dan Kortschak authored
Also add missing copyright headers with year determined from git log. Change-Id: Iafc9881e746543f0a582dad2b0874d8399baf618 Reviewed-on: https://go-review.googlesource.com/122415Reviewed-by:
Rob Pike <r@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dan Kortschak authored
Change-Id: Ic636be3ffe5c9e9dc0dd8faba7898142f5231d15 Reviewed-on: https://go-review.googlesource.com/122417Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 05 Jul, 2018 3 commits
-
-
Michael Munday authored
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. Fixes #25269. Change-Id: I0e44948957a7faff51c7d27c0b7746ed6e2d47bb Reviewed-on: https://go-review.googlesource.com/122235Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
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. Fixes #26209 Change-Id: I43a502beefd626eb810ffd8753e269a55dff8248 Reviewed-on: https://go-review.googlesource.com/122196Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
John Leidegren authored
There is no "window" global in a web worker context. Use "self" instead. Fixes #26192 Change-Id: I6c6f3db6c3d3d9ca00a473f8c18b849bc07a0017 Reviewed-on: https://go-review.googlesource.com/122055 Run-TryBot: Richard Musiol <neelance@gmail.com> Reviewed-by:
Richard Musiol <neelance@gmail.com>
-
- 04 Jul, 2018 4 commits
-
-
Daniel Martí authored
Use an HTML comment with triple dashes for the copypright header, which means that the paragraph will be ignored when rendering both HTML and TeX. While at it, quote "GC", and properly link to internal/ssa/README.md. Change-Id: Ib18529d2fc777d836e74726ff1cfe685e08b063c Reviewed-on: https://go-review.googlesource.com/109875Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Ian Lance Taylor authored
Along with CL 122135, Fixes #26197 Change-Id: I61e8cfb0dcc39885acf8ffa1ffb34cbbe4dc1dc3 Reviewed-on: https://go-review.googlesource.com/122155 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Nikhil Benesch authored
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/102438Reviewed-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
We already remove -rdynamic if -static appears in -extldflags. Extend that to apply to CGO_LDFLAGS and #cgo LDFLAGS as well. Updates #26197 Change-Id: Ibb62d1b20726916a12fd889acb05c1c559a5ace2 Reviewed-on: https://go-review.googlesource.com/122135 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 03 Jul, 2018 2 commits
-
-
Paul Jolly authored
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>
-
Agniva De Sarker authored
Fixes #25911 Change-Id: Id3b5ea5494544e9e7f889831cefaf080cae8865d Reviewed-on: https://go-review.googlesource.com/120655Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-