- 20 Oct, 2017 12 commits
-
-
David Crawshaw authored
For #22095 Change-Id: Iba3dffc782cecc15ea0e90a971a2734729984945 Reviewed-on: https://go-review.googlesource.com/70834 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
David Crawshaw authored
For #22095 Change-Id: Ica6b3391541fe5a0355620d7c4a5107cf53eee82 Reviewed-on: https://go-review.googlesource.com/70833 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Joe Tsai authored
The Reader implementation is slow because it operates on a rune-by-rune basis via bufio.Reader.ReadRune. We speed this up by operating on entire lines that we read from bufio.Reader.ReadSlice. In order to ensure that we read the full line, we augment ReadSlice in our Reader.readLine method to automatically expand the slice if bufio.ErrBufferFull is every hit. This change happens to fix #19410 because it no longer relies on rune-by-rune parsing and only searches for the relevant delimiter rune. In order to keep column accounting simple and consistent, this change reverts parts of CL 52830. This CL is an alternative to CL 36270 and builds on some of the ideas from that change by Diogo Pinela. name old time/op new time/op delta Read-8 3.12µs ± 1% 2.54µs ± 2% -18.76% (p=0.000 n=10+9) ReadWithFieldsPerRecord-8 3.12µs ± 1% 2.53µs ± 1% -18.91% (p=0.000 n=9+9) ReadWithoutFieldsPerRecord-8 3.13µs ± 0% 2.57µs ± 3% -18.07% (p=0.000 n=10+10) ReadLargeFields-8 52.3µs ± 1% 5.3µs ± 2% -89.93% (p=0.000 n=10+9) ReadReuseRecord-8 2.05µs ± 1% 1.40µs ± 1% -31.48% (p=0.000 n=10+9) ReadReuseRecordWithFieldsPerRecord-8 2.05µs ± 1% 1.41µs ± 0% -31.03% (p=0.000 n=10+9) ReadReuseRecordWithoutFieldsPerRecord-8 2.06µs ± 1% 1.40µs ± 1% -31.70% (p=0.000 n=9+10) ReadReuseRecordLargeFields-8 50.9µs ± 0% 4.1µs ± 3% -92.01% (p=0.000 n=10+10) name old alloc/op new alloc/op Read-8 664B ± 0% 664B ± 0% ReadWithFieldsPerRecord-8 664B ± 0% 664B ± 0% ReadWithoutFieldsPerRecord-8 664B ± 0% 664B ± 0% ReadLargeFields-8 3.94kB ± 0% 3.94kB ± 0% ReadReuseRecord-8 24.0B ± 0% 24.0B ± 0% ReadReuseRecordWithFieldsPerRecord-8 24.0B ± 0% 24.0B ± 0% ReadReuseRecordWithoutFieldsPerRecord-8 24.0B ± 0% 24.0B ± 0% ReadReuseRecordLargeFields-8 2.98kB ± 0% 2.98kB ± 0% name old allocs/op new allocs/op Read-8 18.0 ± 0% 18.0 ± 0% ReadWithFieldsPerRecord-8 18.0 ± 0% 18.0 ± 0% ReadWithoutFieldsPerRecord-8 18.0 ± 0% 18.0 ± 0% ReadLargeFields-8 24.0 ± 0% 24.0 ± 0% ReadReuseRecord-8 8.00 ± 0% 8.00 ± 0% ReadReuseRecordWithFieldsPerRecord-8 8.00 ± 0% 8.00 ± 0% ReadReuseRecordWithoutFieldsPerRecord-8 8.00 ± 0% 8.00 ± 0% ReadReuseRecordLargeFields-8 12.0 ± 0% 12.0 ± 0% Updates #22352 Updates #19019 Fixes #16791 Fixes #19410 Change-Id: I31c27cfcc56880e6abac262f36c947179b550bbf Reviewed-on: https://go-review.googlesource.com/72150Reviewed-by:
-
Ian Lance Taylor authored
On systems that use kqueue, we always register descriptors for both EVFILT_READ and EVFILT_WRITE. On at least FreeBSD and OpenBSD, when the write end of a pipe is registered for EVFILT_READ and EVFILT_WRITE events, and the read end of the pipe is closed, kqueue reports an EVFILT_READ event with EV_EOF set, but does not report an EVFILT_WRITE event. Since the write to the pipe is waiting for an EVFILT_WRITE event, closing the read end of a pipe can cause the write end to hang rather than attempt another write which will fail with EPIPE. Fix this by treating EVFILT_READ with EV_EOF set as making both reads and writes ready to proceed. The real test for this is in CL 71770, which tests using various timeouts with pipes. Updates #22114 Change-Id: Ib23fbaaddbccd8eee77bdf18f27a7f0aa50e2742 Reviewed-on: https://go-review.googlesource.com/71973Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Matthew Dempsky authored
Fixes #22342. Change-Id: Ic942162e98dce5749e381a31d58b0bf16c7d6f98 Reviewed-on: https://go-review.googlesource.com/72132 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Cherry Zhang authored
Since inlining budget calculation is fixed in CL 70151 runtime.nextFreeFast is no longer inlineable on MIPS64x because it does not support Ctz64 as intrinsic. Skip the test. Updates #22239. Change-Id: Id00d55628ddb4b48d27aebfa10377a896765d569 Reviewed-on: https://go-review.googlesource.com/72271 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
This hack existed because cmd/go used to install (write) and then run cmd/cgo in the same invocation, and writing and then running a program is a no-no in modern multithreaded Unix programs (see #22315). As of CL 68338, cmd/go no longer installs any programs that it then tries to use. It never did this for any program other than cgo, and CL 68338 removed that special case for cgo. Now this special case, added for #3001 long ago, can be removed too. Change-Id: I338f1f8665e9aca823e33ef7dda9d19f665e4281 Reviewed-on: https://go-review.googlesource.com/71571 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
build.go - commands and misc helpers action.go - action graph construction exec.go - action graph execution gc.go - gc toolchain gccgo.go - gccgo toolchain Change-Id: I39b6e2490ac05334c2321e9ad88df694a6efa82f Reviewed-on: https://go-review.googlesource.com/70671 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
It uses the build ID, which is soon to be internal to package work. Luckily it is also only called from package work. Change-Id: I5e6662cfe667bdc9190f086be733105ad65a3191 Reviewed-on: https://go-review.googlesource.com/70670 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Where GCC says "unrecognized command line option", clang says "unknown argument". This distinction usually doesn't matter because the compiler will also exit with a non-zero status, but clang 3.4 reportedly exits with a zero status after reporting an unknown argument. Change-Id: Ieb69ea352a8de0cd4171a1c26708dfe523421cfa Reviewed-on: https://go-review.googlesource.com/72151 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Damien Neil <dneil@google.com>
-
Hana Kim authored
When traceviewer encounters a failure of json trace import due to data error, onImportFail tried to access an error variable which was not yet defined. Change-Id: I431be03f179aafacaf1fd3c62a6337e8b5bd18fb Reviewed-on: https://go-review.googlesource.com/71970Reviewed-by:
-
Michael Munday authored
The test already contained logic to do this however it did not match the error "cannot find 'ld'" which appears to be how gcc fails when ld.gold is missing. Fixes #22340. Change-Id: I841248cc489b8fa72bc00a95000ad405f9ef8a4f Reviewed-on: https://go-review.googlesource.com/72111 Run-TryBot: Michael Munday <mike.munday@ibm.com> Reviewed-by:
-
- 19 Oct, 2017 12 commits
-
-
Ben Burkert authored
A 1XX, 204, or 304 response may not include a response body according to RFC 7230, section 3.3.3. If a buggy server returns a 204 or 304 response with a body that is chunked encoded, the invalid body is currently made readable in the Response. This can lead to data races due to the transport connection's read loop which does not wait for the body EOF when the response status is 204 or 304. The correct behavior is to ignore the body on a 204 or 304 response, and treat the body data as the beginning of the next request on the connection. Updates #22330. Change-Id: I89a457ceb783b6f66136d5bf9be0a9b0a04fa955 Reviewed-on: https://go-review.googlesource.com/71910Reviewed-by:
Tom Bergan <tombergan@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Tom Bergan <tombergan@google.com>
-
griesemer authored
For #22341. Change-Id: I7e586c58075e4c835ef97701db2f38bdf7558521 Reviewed-on: https://go-review.googlesource.com/71974 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
-
griesemer authored
https://golang.org/cl/71750 specifies iota values as indices, thus making them independent from nested constant declarations. This CL removes some of the comments in the examples that were still referring to the old notion of iotas being incremented and reset. As an aside, please note that the spec still permits the use of iota in a nested function (like before). Specifically, the following cases are permitted by the spec (as before): 1) const _ = len([iota]int{}) 2) const _ = unsafe.Sizeof(func(){ _ = iota }) For #15550. Change-Id: I9e5fec75daf7b628b1e08d970512397e9c348923 Reviewed-on: https://go-review.googlesource.com/71912Reviewed-by:
Rob Pike <r@golang.org> Reviewed-by:
-
Matthew Dempsky authored
racewalk's "foreach" function applies a function to all of a Node's immediate children, but with a non-idiomatic signature. This CL reworks it to recursively iterate over the entire subtree rooted at Node and provides a way to short-circuit iteration. Passes toolstash -cmp for std cmd with -race. Change-Id: I738b73953d608709802c97945b7e0f4e4940d3f4 Reviewed-on: https://go-review.googlesource.com/71911 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Artyom Pervukhin authored
Change-Id: I094af156e7b8c31af3162d943a8c61268803ab89 Reviewed-on: https://go-review.googlesource.com/71830Reviewed-by:
Gabriel Aszalos <gabriel.aszalos@gmail.com> Reviewed-by:
-
Russ Cox authored
On modern Unix systems it is basically impossible for a multithreaded program to open a binary for write, close it, and then fork+exec that same binary. So don't write the binary if we're going to fork+exec it. This fixes the ETXTBSY flakes. Fixes #22220. See also #22315. Change-Id: I6be4802fa174726ef2a93d5b2f09f708da897cdb Reviewed-on: https://go-review.googlesource.com/71570 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
griesemer authored
Issue #15550 is clearly an esoteric case but the spec was silent about it and we had diverging implementations. By making `iota` and index that is relative to the respective constant declaration, nested const declarations won't affect outer values of `iota`. cmd/compile and go/types already follow this semantics. Fixes #15550. Change-Id: If138189e3ea4373f8ba50ac6fb1d219b481f8698 Reviewed-on: https://go-review.googlesource.com/71750Reviewed-by:
-
Jed Denlea authored
golang.org/cl/37258 was committed to fix issue #16146. This patch seemed intent to allow at most one dangling byte. But, as implemented, many more bytes may actually slip through. This is because the LZW layer creates a bufio.Reader which will itself consume data beyond the end of the LZW stream, and this isn't accounted for anywhere. This change means to avoid the allocation of the bufio.Reader by making blockReader implement io.ByteReader. Further, it adds a close() method which detects extra data in the block sequence. To avoid any regressions with poorly encoded GIFs which may have worked accidentally, there are no restrictions on how many extra bytes may exist in the final full sub-block that contained LZW data. If the end of the LZW stream happened to align with the end of a sub-block, at most one more sub-block with a length of 1 byte may exist before the block terminator. This change aims to be at least as performant as the prior implementation. But the primary gain is avoiding the allocation of a bufio.Reader per frame: name old time/op new time/op delta Decode-8 276µs ± 0% 275µs ± 2% ~ (p=0.690 n=5+5) name old speed new speed delta Decode-8 55.9MB/s ± 0% 56.3MB/s ± 2% ~ (p=0.690 n=5+5) name old alloc/op new alloc/op delta Decode-8 49.2kB ± 0% 44.8kB ± 0% -9.10% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Decode-8 269 ± 0% 267 ± 0% -0.74% (p=0.008 n=5+5) Change-Id: Iec4f9b895561ad52266313fbc73ec82c070c3349 Reviewed-on: https://go-review.googlesource.com/68350 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Austin Clements authored
When building test binaries, we build one archive with all of the test sources and a second archive with the generated test package main and link them together. If the test sources are themselves in package main and the test was compiled with non-default compiler flags, then both archives will contain a go.cuinfo.producer.main symbol, leading to a duplicate symbol failure. This has been causing test build failures on darwin-arm-a1428ios, darwin-arm64-a1549ios, linux-amd64-noopt, android-arm-wiko-fever, and android-arm64-wiko-fever since CL 71430 added this symbol. This CL should fix the build. Change-Id: I69051c846e7c0d97395a865a361cae07f411f9ad Reviewed-on: https://go-review.googlesource.com/71771 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
Than McIntosh <thanm@google.com> Reviewed-by:
-
Alex Brainman authored
CL 70310 dropped TODO while moving code. Add TODO back, so we do not forget. Change-Id: I3599ac02743bd35fb9556fdc238e9c72cf7f718f Reviewed-on: https://go-review.googlesource.com/71590Reviewed-by:
-
griesemer authored
Fixes #22258. Change-Id: I43e68f1cf3163e1a041ebff2734ff2cb7943f695 Reviewed-on: https://go-review.googlesource.com/71431Reviewed-by:
-
Ian Lance Taylor authored
No test because at present it is never called in a way that fails. When #22114 is implemented, failure will be possible. Not including this change in that work because this change is separable and clearly correct. Updates #22114 Change-Id: I81eb9eec8800e8082d918c0e5fb71282f538267e Reviewed-on: https://go-review.googlesource.com/71751 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Joe Tsai <joetsai@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 18 Oct, 2017 10 commits
-
-
Heschi Kreinick authored
StructField.ByteSize is almost always unset; document that Type.Size() is the place to look. The dwarf package doesn't spend much effort teaching you DWARF, so I don't know what level of handholding is appropriate. Still, no harm in a little comment. Closes #21093 Change-Id: I0ed8cad2fa18e10a47d264ff16c176d603d6033c Reviewed-on: https://go-review.googlesource.com/71671 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Wei Congrui authored
Fixes #21800 Change-Id: I6c61d3543f28e9951b2a219b3c7298077b38f29e Reviewed-on: https://go-review.googlesource.com/66210 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
This adds a whitelisted subset of compiler flags to the DW_AT_producer DWARF attribute of each package compilation unit DIE. This is common practice in DWARF and can help debuggers determine the quality of the produced debugging information. Fixes #22168. Change-Id: I1b994ef2262aa9b88b68eb6e883695d1103acc58 Reviewed-on: https://go-review.googlesource.com/71430Reviewed-by:
-
Austin Clements authored
Currently mmap returns an unsafe.Pointer that encodes OS errors as values less than 4096. In practice this is okay, but it borders on being really unsafe: for example, the value has to be checked immediately after return and if stack copying were ever to observe such a value, it would panic. It's also not remotely idiomatic. Fix this by making mmap return a separate pointer value and error, like a normal Go function. Updates #22218. Change-Id: Iefd965095ffc82cc91118872753a5d39d785c3a6 Reviewed-on: https://go-review.googlesource.com/71270 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Heschi Kreinick authored
Set DW_AT_variable_parameter on DW_TAG_formal_parameters that are actually return values. variable_parameter is supposed to indicate inout parameters, but Go doesn't really have those, and DWARF doesn't have explicit support for multiple return values. This seems to be the best compromise, especially since the implementation of the two is very similar -- both are stack slots. Fixes #21100 Change-Id: Icebabc92b7b397e0aa00a7237478cce84ad1a670 Reviewed-on: https://go-review.googlesource.com/71670 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Tom Bergan authored
Updates http2 to x/net/http2 git rev 1087133bc4a for: http2: reject DATA frame before HEADERS frame https://golang.org/cl/56770 http2: respect peer's SETTINGS_MAX_HEADER_LIST_SIZE in ClientConn https://golang.org/cl/29243 http2: reset client stream after processing response headers https://golang.org/cl/70510 Also updated TestRequestLimit_h2 as the behavior changed slightly due to https://golang.org/cl/29243. Fixes #13959 Fixes #20521 Fixes #21466 Change-Id: Iac659694f3a48b8bd485546a4f96a932e3056026 Reviewed-on: https://go-review.googlesource.com/71611 Run-TryBot: Tom Bergan <tombergan@google.com> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Fixes Darwin 386 build. It turns out that the Darwin pthread_create function saves the SSE registers, and therefore requires an aligned stack. This worked before https://golang.org/cl/70530 because the stack sizes were chosen to leave the stack aligned. Change-Id: I911a9e8dcde4e41e595d5ef9b9a1ca733e154de6 Reviewed-on: https://go-review.googlesource.com/71432Reviewed-by:
-
Dhananjay Nakrani authored
Fixes #13265. Change-Id: I792eb4ee26bef8a56e279e23f9802cb39019e0d0 Reviewed-on: https://go-review.googlesource.com/34929Reviewed-by:
-
Tim Cooper authored
Fixes #22292 Change-Id: I016e5f2b8624a6ebaf11a693a0f6d94d7b0d3f92 Reviewed-on: https://go-review.googlesource.com/71550Reviewed-by:
Daniel Theophanes <kardianos@gmail.com>
-
Russ Cox authored
More generally I'm concerned about these tests using $GOROOT/src/cmd/go as scratch space, especially combined wtih tg.parallel() - it's easy to believe some other test might inadvertently also try to write x.exe about the same time. This CL only solves the "didn't clean up x.exe" problem and leaves for another day the "probably shouldn't write to cmd/go at all" problem. Fixes #22266. Change-Id: I651534d70e2d360138e0373fb4a316081872550b Reviewed-on: https://go-review.googlesource.com/71410 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 17 Oct, 2017 6 commits
-
-
griesemer authored
Nowhere in the spec did we mention the import path for package unsafe. Now we do. Fixes #22308. Change-Id: Ifd42c873188e898c597cdee4284e7a9d234a9282 Reviewed-on: https://go-review.googlesource.com/71373Reviewed-by:
-
Tim Cooper authored
Change-Id: I9d723e49bf2cabf97a09e29e46fd2c426845fd1d Reviewed-on: https://go-review.googlesource.com/71470Reviewed-by:
-
Daniel Theophanes authored
This reverts commit 897080d5. Reason for revert: Fails to fix all the locking issues. Updates #21117 Change-Id: I6fc9cb7897244d6e1af78c089a2bf383258ec049 Reviewed-on: https://go-review.googlesource.com/71450Reviewed-by:
-
Jay Conrod authored
Fixed an error that occurred in atomic mode. cover adds a global variable declaration that forces sync/atomic to be used. fixDirectives was confused by this declaration since it has an invalid position. These declarations are now skipped. Fixes #22309 Change-Id: I84f5fec13ef847fca35ad49f7704fb93b60503e0 Reviewed-on: https://go-review.googlesource.com/71351 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Gabriel Aszalos authored
Simplifies the switch statement in the isZeroValue function by merging the case branches. Change-Id: I5b27939b62808dadac0cef632567b17e0e2b9a1d Reviewed-on: https://go-review.googlesource.com/71390 Run-TryBot: Gabriel Aszalos <gabriel.aszalos@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
griesemer authored
When an opening "{" of a block is missing and after advancing we find a closing "}", it's likely better to assume the end of the block. Fixed and removed TODO. Change-Id: I20c9b4ecca798933a7cd4cbf21185bd4ca04f5f7 Reviewed-on: https://go-review.googlesource.com/71291Reviewed-by:
-
