- 26 Jun, 2015 7 commits
-
-
Dmitry Vyukov authored
Instrument operands of OKEY. Also instrument OSLICESTR. Previously it was not needed because of preceeding bounds checks (which were instrumented). But the preceeding bounds checks have disappeared. Change-Id: I3b0de213e23cbcf5b8ef800abeded5eeeb3f8287 Reviewed-on: https://go-review.googlesource.com/11417Reviewed-by:
Russ Cox <rsc@golang.org>
-
Vincent Batts authored
The issue was identified while working with round trip FileInfo of the headers of hardlinks. Also, additional test cases for hard link handling. (review carried over from http://golang.org/cl/165860043) Fixes #9027 Change-Id: I9e3a724c8de72eb1b0fbe0751a7b488894911b76 Reviewed-on: https://go-review.googlesource.com/6790Reviewed-by:
Russ Cox <rsc@golang.org>
-
Andrew Gerrand authored
Fixes #11402 Change-Id: I195575a54e30ad6d6b1d0996fde34c0163bbd2c2 Reviewed-on: https://go-review.googlesource.com/11530Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Matt Layher authored
Change-Id: I193b416ac91b4fa9234d30a1c1c58b3f0a71f398 Reviewed-on: https://go-review.googlesource.com/11543Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Aaron Jacobs authored
Change-Id: Ifb8e4e13c7778a7c0113190051415e096f5db94f Reviewed-on: https://go-review.googlesource.com/11390Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Rob Pike authored
No need to update the date; this is not a spec change. Change-Id: I10a31234ed985c59e5d9b5328664a36661cef31e Reviewed-on: https://go-review.googlesource.com/11531Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Andrew Gerrand authored
Fixes #10236 Change-Id: Ife85513efda48af81c267b753da2ac7317cdfe75 Reviewed-on: https://go-review.googlesource.com/11479Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 25 Jun, 2015 13 commits
-
-
Brad Fitzpatrick authored
Some old buggy browsers sent extra CRLF(s) after POST bodies. Skip over them before reading subsequent requests. Fixes #10876 Change-Id: I62eacf2b3e985caffa85aee3de39d8cd3548130b Reviewed-on: https://go-review.googlesource.com/11491Reviewed-by:
Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Mikio Hara authored
Change-Id: I668b18b1e6901c59cf170e0c1cde9a3923c0cb13 Reviewed-on: https://go-review.googlesource.com/11472Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Rob Pike authored
Change-Id: Ie2aba3d5069d88548414f7d76b9b6efb9acf0393 Reviewed-on: https://go-review.googlesource.com/11477Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Dmitry Vyukov authored
At some point it silently stopped recognizing test output. Meanwhile two tests degraded... Change-Id: I90a0325fc9aaa16c3ef16b9c4c642581da2bb10c Reviewed-on: https://go-review.googlesource.com/11416Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
If a client sent a POST with a huge request body, calling req.Body.Close in the handler (which is implicit at the end of a request) would end up consuming it all. Put a cap on that, using the same threshold used elsewhere for similar cases. Fixes #9662 Change-Id: I26628413aa5f623a96ef7c2609a8d03c746669e5 Reviewed-on: https://go-review.googlesource.com/11412Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Brad Fitzpatrick authored
Fixes #11383 Change-Id: I7ef0bb8b535ef513afdfcda19317ae4ff21f7166 Reviewed-on: https://go-review.googlesource.com/11490Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Todd Neal authored
Negative width arguments now left align the way a minus-width in the format string aligns. The minus in the format string overrides the sign of the argument as in C. Precision behavior is modified to include an error if the argument is negative. This differs from a negative precision in a format string which just terminates the format. Additional checks for large magnitude widths and precisions are added to make the runtime behavior (failure, but with different error messages), more consistent between format string specified width/precision and argument specified width/precision. Fixes #11376 Change-Id: I8c7ed21088e9c18128a45d4c487c5ab9fafd13ef Reviewed-on: https://go-review.googlesource.com/11405Reviewed-by:
Rob Pike <r@golang.org> Run-TryBot: Rob Pike <r@golang.org>
-
Matthew Dempsky authored
Instead of ambiguously referring to "the Client's CheckRedirect function" in Head, describe the default behavior like for Get as users aren't expected to change DefaultClient.CheckRedirect. While here, use consistent punctuation for the Get and Head Client method documentation. Change-Id: I9e7046c73b0d0bc4de002234924d9e7c59aceb41 Reviewed-on: https://go-review.googlesource.com/11362Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Rob Pike authored
Just a copy, other than adding a header, preparatory to preparing the release notes. Change-Id: Ia4dc27777b96b1e898d9873e7d38e6e795057698 Reviewed-on: https://go-review.googlesource.com/11474Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #8296 Change-Id: I71b330a0f961d46ae4ed81d5f3f5ce5bf708a29a Reviewed-on: https://go-review.googlesource.com/11411Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Keith Randall authored
See issue #11354. Change-Id: I6817d499e6c02e4a9c83f80bc66a2bee368a69ec Reviewed-on: https://go-review.googlesource.com/11406Reviewed-by:
Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
The ListenAndServerTLS function still requires the certFile and keyFile, but the Server.ListenAndServerTLS method doesn't need to require the certFile and keyFile if the Server.TLSConfig.Certificates are already populated. Fixes #8599 Change-Id: Id2e3433732f93e2619bfd78891f775d89f1d651e Reviewed-on: https://go-review.googlesource.com/11413Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Brad Fitzpatrick authored
Fixes #8137 Change-Id: Icd94bbe430a3ef333248425449b5fc678edb0343 Reviewed-on: https://go-review.googlesource.com/11410Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
- 24 Jun, 2015 9 commits
-
-
Russ Cox authored
Fixes #11379. Change-Id: Idbb5c3faad472b77e9867dd2d4551fef5e4ac5f1 Reviewed-on: https://go-review.googlesource.com/11421Reviewed-by:
Rob Pike <r@golang.org>
-
Russ Cox authored
Somehow we missed this! Fixes #11387. Change-Id: Ida08fe52eff7da2ef7765b4cf35a39a301420c43 Reviewed-on: https://go-review.googlesource.com/11460Reviewed-by:
David Chase <drchase@google.com>
-
Russ Cox authored
For debuggers and other program inspectors. Fixes #9914. Change-Id: I670728cea28c045e6eaba1808c550ee2f34d16ff Reviewed-on: https://go-review.googlesource.com/11341Reviewed-by:
Austin Clements <austin@google.com>
-
Didier Spezia authored
The code formatting mechanism can be applied to partial Go code, such as a list of statements. The statements are wrapped into a function definition (to be parsed fine), and unwrapped after formatting. When the statements contain //line annotations, it may fail, because not all comments are flushed by the printer before the final '}'. Formatting "\ta()\n//line :1" results in "\ta() }\n\n//line", which is wrong. Tweaked the wrapping/unwrapping code to make sure comments are flushed before the '}'. Fixes #11276 Change-Id: Id15c80279b0382ee9ed939cca1647f525c4929f5 Reviewed-on: https://go-review.googlesource.com/11282 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Dmitry Vyukov authored
The test is flaky on builders lately. I don't see any issues other than usage of very small sleeps. So increase the sleeps. Also take opportunity to refactor the code. On my machine this change significantly reduces failure rate with GOMAXPROCS=2. I can't reproduce the failure with GOMAXPROCS=1. Fixes #10726 Change-Id: Iea6f10cf3ce1be5c112a2375d51c13687a8ab4c9 Reviewed-on: https://go-review.googlesource.com/9803Reviewed-by:
Austin Clements <austin@google.com>
-
Brad Fitzpatrick authored
Fixes #11208 Change-Id: I35cc94129577b2a977fd35aafb0a5fb02c534a7c Reviewed-on: https://go-review.googlesource.com/11414Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Russ Cox authored
To date, the behavior has depended on whether we're using cgo and in turn what the host resolver does. Most host resolvers will "resolve" IP addresses, but the non-cgo pure Go path has not. This CL makes resolution of IP addresses always work, even if we're not using cgo and even if the host resolver does not "resolve" IP addresses. Fixes #11335. Change-Id: I19e82be968154d94904bb2f72e9c17893019a909 Reviewed-on: https://go-review.googlesource.com/11420Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Carlos C authored
Change-Id: I42a952b04a56fb888fa7d5d9c2b56cbdd3434034 Reviewed-on: https://go-review.googlesource.com/11246Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Andrew Gerrand authored
Fixes #9637 Fixes #10120 Change-Id: I3728239089efb94d04cd4115c9f840afd7badeaf Reviewed-on: https://go-review.googlesource.com/9715Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 23 Jun, 2015 9 commits
-
-
Robert Griesemer authored
Not a language change. Fixes #11350. Change-Id: I9b905f17d1ef2722cab4bae38a037270165c7d95 Reviewed-on: https://go-review.googlesource.com/11369Reviewed-by:
Rob Pike <r@golang.org>
-
Robert Griesemer authored
Port of https://go-review.googlesource.com/11365 Fixes #11357. Change-Id: Icd20fa038696a8853d1d14477e1c1132938b3e2e Reviewed-on: https://go-review.googlesource.com/11368Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
Port of https://go-review.googlesource.com/11363. Fixes #11367. Change-Id: Ie0a82bcfab782c514d1947e7a6b190e286afd159 Reviewed-on: https://go-review.googlesource.com/11367Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Austin Clements authored
When heapBitsSetType repeats a source bitmap with a scalar tail (typ.ptrdata < typ.size), it lays out the tail upon reaching the end of the source bitmap by simply increasing the number of bits claimed to be in the incoming bit buffer. This causes later iterations to read the appropriate number of zeros out of the bit buffer before starting on the next repeat of the source bitmap. Currently, however, later iterations of the loop continue to read bits from the source bitmap *regardless of the number of bits currently in the bit buffer*. The bit buffer can only hold 32 or 64 bits, so if the scalar tail is large and the padding bits exceed the size of the bit buffer, the read from the source bitmap on the next iteration will shift the incoming bits into oblivion when it attempts to put them in the bit buffer. When the buffer does eventually shift down to where these bits were supposed to be, it will contain zeros. As a result, words that should be marked as pointers on later repetitions are marked as scalars, so the garbage collector does not trace them. If this is the only reference to an object, it will be incorrectly freed. Fix this by adding logic to drain the bit buffer down if it is large instead of reading more bits from the source bitmap. Fixes #11286. Change-Id: I964432c4b9f1cec334fc8c3da0ff16460203feb6 Reviewed-on: https://go-review.googlesource.com/11360Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
h_spans can be accessed concurrently without synchronization from other threads, which means it needs the appropriate memory barriers on weakly ordered machines. It happens to already have the necessary memory barriers because all accesses to h_spans are currently protected by the heap lock and the unlocks happen in exactly the places where release barriers are needed, but it's easy to imagine that this could change in the future. Document the fact that we're depending on the barrier implied by the unlock. Related to issue #9984. Change-Id: I1bc3c95cd73361b041c8c95cd4bb92daf8c1f94a Reviewed-on: https://go-review.googlesource.com/11361Reviewed-by:
Rick Hudson <rlh@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Robert Griesemer authored
Port of https://go-review.googlesource.com/11344 to std repo. Fixes #11325. Change-Id: I634beaf77cbaeb09de50aa1410e8c53fc37b19df Reviewed-on: https://go-review.googlesource.com/11317Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Rob Pike authored
There are two conditions to worry about: 1) The shift count cannot be negative. Since the evaluator uses unsigned arithmetic throughout, this means checking that the high bit of the shift count is always off, which is done by converting to int64 and seeing if the result is negative. 2) For right shifts, the value cannot be negative. We don't want a high bit in the value because right shifting a value depends on the sign, and for clarity we always want unsigned shifts. Next step is to build some testing infrastructure for the parser. Change-Id: I4c46c79989d02c107fc64954403fc18613763f1d Reviewed-on: https://go-review.googlesource.com/11326Reviewed-by:
Russ Cox <rsc@golang.org>
-
Andrew Bonventre authored
It was otherwise not being preserved across specific Decode->Encode->Decode calls. Fixes #11287 Change-Id: I40602da7fa39ec67403bed52ff403f361c6171bb Reviewed-on: https://go-review.googlesource.com/11256Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Rob Pike authored
Documentation change only. Fixes #11247. Change-Id: Ib412de2d643292dbe42b56dee955bdb877aee81b Reviewed-on: https://go-review.googlesource.com/11329Reviewed-by:
David Symonds <dsymonds@golang.org>
-
- 22 Jun, 2015 2 commits
-
-
Todd Neal authored
This appears to be some legacy which is no longer used. Change-Id: I469beb59a90853e8de910158f179b32f1aa14c7d Reviewed-on: https://go-review.googlesource.com/11304Reviewed-by:
Andrew Gerrand <adg@golang.org> Run-TryBot: Andrew Gerrand <adg@golang.org>
-
Rob Pike authored
Some of those consts were supposed to be vars. Caught by Ingo Oeser. Change-Id: Ifc12e4a8ee61ebf5174e4ad923956c546dc096e2 Reviewed-on: https://go-review.googlesource.com/11296Reviewed-by:
Andrew Gerrand <adg@golang.org>
-