- 04 Oct, 2018 10 commits
-
-
Austin Clements authored
mheap_.treapalloc.alloc() already returns a zeroed treapNode. Don't bother re-zeroing all of the fields. Change-Id: Iea317040fbb72dfe5ef1e2c56c287680b065f2d9 Reviewed-on: https://go-review.googlesource.com/c/139460 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tobias Klauser authored
This fixes the build for long-running tests after CL 139338 Change-Id: Ib8adfa785d41c736188e2ff7e14125de045b96b9 Reviewed-on: https://go-review.googlesource.com/c/139637 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
LookupFieldOrMethod needs to know if a method receiver is a pointer type. Until now this was computed from the the method signature's receiver, which required the method signature to be type-checked. Furthermore, it required the receiver to be set before the method signature was fully type-checked in some cases (see issue #6638). This CL remembers this property during object resolution, when we know it from the source. With this CL, method signatures don't need to be type-checked before they can be looked up; this is a first step towards separating type checking of types and type-checking of associated methods. Updates #23203. Updates #26854. Change-Id: Ie3eb7976e8fe8176ea1b284fa7471a4b7000f80b Reviewed-on: https://go-review.googlesource.com/c/139422 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
-
Matthew Dempsky authored
Change-Id: I0490098a7235458c5aede1135426a9f19f8584a7 Reviewed-on: https://go-review.googlesource.com/c/76312 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
In preparation for followup CL merging TPTR32 and TPTR64, move TPTR32 from the small-types fast path to the generic 64-bit fallback code so that it's in the same case clause as TPTR64. This should be safe, but theoretically it could change semantics because TPTR32 used to always be assumed to be "small", whereas now it will only be considered small for values less than 1<<31. This change is done in a separate CL so that it's more easily identified by git bisection in case it does introduce regressions. Change-Id: I6c7bb253d4e4d95c530a6e05a1147905674b55ca Reviewed-on: https://go-review.googlesource.com/c/139517 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
Change-Id: Ie4bab0b74d5a4e1aecd8501a48176b2e9a3d8c42 Reviewed-on: https://go-review.googlesource.com/c/76311 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Kir Kolyshkin authored
As pointed out in https://github.com/golang/go/issues/26463, HOME (or equivalent) environment variable (rather than the value obtained by parsing /etc/passwd or the like) should be used to obtain user's home directory. Since commit fa1a49aa there's a method to obtain user's home directory -- use it here. Change-Id: I852fbb24249bcfe08f3874fae6e7b9d01d869190 Reviewed-on: https://go-review.googlesource.com/c/139426Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Fraenkel authored
Fixes #13491 Change-Id: Ic0525d8ee90f47d0d23c1485919aee13d2400494 Reviewed-on: https://go-review.googlesource.com/c/139537 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
uropek authored
Change-Id: Id21cdce35963dcdb96cc06252170590224c5aa17 GitHub-Last-Rev: 429dad0ceba123415af308179d0d2aa9773e6323 GitHub-Pull-Request: golang/go#28000 Reviewed-on: https://go-review.googlesource.com/c/139424Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Richard Musiol authored
This commit makes syscall on js/wasm use the asynchronous variants of functions in Node.js' fs module. This enables concurrency and allows the API of the fs module to be implemented with an alternative backend that only supports asynchronous operations. Updates #26051. Change-Id: Ibe1dcc988469fc11c3b8d8d49de439c12ddaafce Reviewed-on: https://go-review.googlesource.com/c/137236 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 03 Oct, 2018 29 commits
-
-
Brad Fitzpatrick authored
Fixes #22614 Change-Id: I220afbaaeab4dec6d59eeeef12107234a77f1587 Reviewed-on: https://go-review.googlesource.com/c/139419Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Don Byington authored
Fixes #27990 Change-Id: I0f09fc6f68cec770b1c26eed2315afbf6bf6cd4d GitHub-Last-Rev: 8486e6d5019c6c21b10e5fcf10a2727cf2705174 GitHub-Pull-Request: golang/go#27991 Reviewed-on: https://go-review.googlesource.com/c/139417 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Lynn Boger authored
The following adds support for load and store instructions with index registers, and adds rules to take advantage of those instructions. Examples of improvements: crypto/rc4: name old time/op new time/op delta RC4_128 445ns ± 0% 404ns ± 0% -9.21% (p=0.029 n=4+4) RC4_1K 3.46µs ± 0% 3.13µs ± 0% -9.29% (p=0.029 n=4+4) RC4_8K 27.0µs ± 0% 24.7µs ± 0% -8.83% (p=0.029 n=4+4) crypto/des: name old time/op new time/op delta Encrypt 276ns ± 0% 264ns ± 0% -4.35% (p=0.029 n=4+4) Decrypt 278ns ± 0% 263ns ± 0% -5.40% (p=0.029 n=4+4) TDESEncrypt 683ns ± 0% 645ns ± 0% -5.56% (p=0.029 n=4+4) TDESDecrypt 684ns ± 0% 641ns ± 0% -6.29% (p=0.029 n=4+4) crypto/sha1: name old time/op new time/op delta Hash8Bytes 661ns ± 0% 635ns ± 0% -3.93% (p=1.000 n=1+1) Hash320Bytes 2.70µs ± 0% 2.56µs ± 0% -5.26% (p=1.000 n=1+1) Hash1K 7.14µs ± 0% 6.78µs ± 0% -5.03% (p=1.000 n=1+1) Hash8K 52.1µs ± 0% 49.4µs ± 0% -5.14% (p=1.000 n=1+1) Change-Id: I03810e90fcc20029975a323f06bfa086c973c2b0 Reviewed-on: https://go-review.googlesource.com/c/135975 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Munday <mike.munday@ibm.com>
-
Brad Fitzpatrick authored
Fixes #26463 Change-Id: Iaef1c7456ffaeadeead6027a37d09c44a3d05bd5 Reviewed-on: https://go-review.googlesource.com/c/139418Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Clément Chigot authored
This commit adds AIX operating system to internal/syscall package for ppc64 architecture. Updates: #25893 Change-Id: I5c3a9d4403ca170a7e894e06e68b83387d09b816 Reviewed-on: https://go-review.googlesource.com/c/138718 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Martin Möhrmann authored
When an invalid UTF-8 byte sequence is decoded in a range loop over a string a utf8.RuneError rune is returned. This is not distinguishable from decoding the valid '\uFFFD' sequence representing utf8.RuneError from a string without further checks within the range loop. The previous Map code did not do any extra checks and would thereby not map invalid UTF-8 byte sequences correctly when those were mapping to utf8.RuneError. Fix this by adding the extra checks necessary to distinguish the decoding of invalid utf8 byte sequences from decoding the sequence for utf8.RuneError when the mapping of a rune is utf8.RuneError. This fix does not result in a measureable performance regression: name old time/op new time/op delta ByteByteMap 1.05µs ± 3% 1.03µs ± 3% ~ (p=0.118 n=10+10) Map/identity/ASCII 169ns ± 2% 170ns ± 1% ~ (p=0.501 n=9+10) Map/identity/Greek 298ns ± 1% 303ns ± 4% ~ (p=0.338 n=10+10) Map/change/ASCII 323ns ± 3% 325ns ± 4% ~ (p=0.679 n=8+10) Map/change/Greek 628ns ± 5% 635ns ± 1% ~ (p=0.460 n=10+9) MapNoChanges 120ns ± 4% 119ns ± 1% ~ (p=0.496 n=10+9) Fixes #26305 Change-Id: I70e99fa244983c5040756fa4549ac1e8cb6022c3 Reviewed-on: https://go-review.googlesource.com/c/131495Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Clément Chigot authored
This commit adds AIX operating system to internal/poll package for ppc64 architecture. Updates: #25893 Change-Id: I9b1da9255012de58f16547c1b18f8840485da170 Reviewed-on: https://go-review.googlesource.com/c/138717 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Clément Chigot authored
This commit adds AIX operating system to runtime package for ppc64 architecture. Only new files and minor changes are in this commit. Others modifications in files like asm_ppc64.s will be in separate commits. Updates: #25893 Change-Id: I9c5e073f5f3debb43b004ad1167694a5afd31cfd Reviewed-on: https://go-review.googlesource.com/c/138716 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Currently, the Windows profile loop isn't robust against racing with unminit. For example, T1 is running profileloop1, T2 is another thread T1: thread := atomic.Loaduintptr(&T2.thread) T2: calls unminit, which does CloseHandle(T2.thread) T1: attempts to suspends T2 In this case the SuspendThread will fail, but currently we ignore this failure and forge ahead, which will cause further failures and probably bad profile data. Handle this race by defending against SuspendThread failing. If SuspendThread succeeds, then we know the thread is no longer going anywhere. Change-Id: I4726553239b17f05ca07a0cf7df49631e0cb550d Reviewed-on: https://go-review.googlesource.com/c/129685 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Austin Clements authored
The debug call injection tests will freeze when run under a debugger because they depend on catching SIGTRAP, which is usually swallowed by a debugger. Change-Id: If6b86ca279b0489182990dd513444ca3062973f1 Reviewed-on: https://go-review.googlesource.com/c/139437 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Daniel Martí authored
And start using it elsewhere in the standard library, removing the copies in the process. While at it, rewrite the io.WriteString godoc to be more clear, since it can now make reference to the defined interface. Fixes #27946. Change-Id: Id5ba223c09c19e5fb49815bd3b1bd3254fc786f3 Reviewed-on: https://go-review.googlesource.com/c/139457 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Allocate a long linked list on the stack. This tests both lots of live stack objects, and lots of intra-stack pointers to those objects. Change-Id: I169e067416455737774851633b1e5367e10e1cf2 Reviewed-on: https://go-review.googlesource.com/c/135296 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Keith Randall authored
When a function triggers a signal (like a segfault which translates to a nil pointer exception) during execution, a sigpanic handler is just below it on the stack. The function itself did not stop at a safepoint, so we have to figure out what safepoint we should use to scan its stack frame. Previously we used the site of the most recent defer to get the live variables at the signal site. That answer is not quite correct, as explained in #27518. Instead, use the site of a deferreturn call. It has all the right variables marked as live (no args, all the return values, except those that escape to the heap, in which case the corresponding PAUTOHEAP variables will be live instead). This CL requires stack objects, so that all the local variables and args referenced by the deferred closures keep the right variables alive. Fixes #27518 Change-Id: Id45d8a8666759986c203181090b962e2981e48ca Reviewed-on: https://go-review.googlesource.com/c/134637Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Keith Randall authored
The previous CL introduced stack objects. This CL removes the old ambiguously live liveness analysis. After this CL we're relying on stack objects exclusively. Update a bunch of liveness tests to reflect the new world. Fixes #22350 Change-Id: I739b26e015882231011ce6bc1a7f426049e59f31 Reviewed-on: https://go-review.googlesource.com/c/134156Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Keith Randall authored
Rework how the compiler+runtime handles stack-allocated variables whose address is taken. Direct references to such variables work as before. References through pointers, however, use a new mechanism. The new mechanism is more precise than the old "ambiguously live" mechanism. It computes liveness at runtime based on the actual references among objects on the stack. Each function records all of its address-taken objects in a FUNCDATA. These are called "stack objects". The runtime then uses that information while scanning a stack to find all of the stack objects on a stack. It then does a mark phase on the stack objects, using all the pointers found on the stack (and ancillary structures, like defer records) as the root set. Only stack objects which are found to be live during this mark phase will be scanned and thus retain any heap objects they point to. A subsequent CL will remove all the "ambiguously live" logic from the compiler, so that the stack object tracing will be required. For this CL, the stack tracing is all redundant with the current ambiguously live logic. Update #22350 Change-Id: Ide19f1f71a5b6ec8c4d54f8f66f0e9a98344772f Reviewed-on: https://go-review.googlesource.com/c/134155Reviewed-by: Austin Clements <austin@google.com>
-
Matthew Dempsky authored
This CL removes all unused code from bimport.go and bexport.go. In the interest of keeping this CL strictly delete-only and easier to review, the task of consolidating the vestigial code elsewhere is left to future CLs. Change-Id: Ib757cc27e3fe814cbf534776d026e4d4cddfc6db Reviewed-on: https://go-review.googlesource.com/c/139338 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
The new indexed package export format appears stable, and no reports of needing to revert back to binary package export. This CL disables the binary package export format by mechanically replacing 'flagiexport' with 'true', and then superficial code cleanups to keep the resulting code idiomatic. The resulting dead code is removed in a followup CL. Change-Id: Ic30d85f78778a31d279a56b9ab14e80836d50135 Reviewed-on: https://go-review.googlesource.com/c/139337 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
Produced using gofmt -r. Change-Id: I4184940618a3a1dac563a9d20aafe1d9f705300c Reviewed-on: https://go-review.googlesource.com/c/76310 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Florian Uekermann authored
Unsuccessful calls to LoadLocation previously returned the first error encountered while traversing the default list of sources, but ignored errors from sources specified by ZONEINFO. Whether errors indicating missing zones or sources were ignored in this process differed between kinds of sources. With this change, unsuccessful calls to LoadLocation always return the first error, not counting errors indicating missing zones or sources. Change-Id: Ief2c088f1df53d974b837e6565e784c2b9928ef4 Reviewed-on: https://go-review.googlesource.com/c/81595 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Tim authored
The old one was rather confusing - it makes it sound like the user has done something wrong. Change-Id: Ibc7411f4f1d5f6c66fbcaac64bb05b0743354418 GitHub-Last-Rev: 09290accddb23848ee80d641e4f2bcf6ef686e01 GitHub-Pull-Request: golang/go#27979 Reviewed-on: https://go-review.googlesource.com/c/139102Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Daniel Theophanes <kardianos@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Url authored
If an illegal header write is detected, find the first caller outside of net/http using runtime.CallersFrames and include the call site in the log message. Fixes #18761 Change-Id: I92be00ac206c6ebdd60344ad7bf40a7c4c188547 Reviewed-on: https://go-review.googlesource.com/c/130997Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Zhou Peng authored
Don't worry, this patch just remove trailing whitespace from assembly files, and does not touch any logical changes. Change-Id: Ia724ac0b1abf8bc1e41454bdc79289ef317c165d Reviewed-on: https://go-review.googlesource.com/c/113595Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Weerasak Chongnguluam authored
When deadline has already passed, current context is canceled before return cancel function. So is unnecessary to call cancel with remove from parent again in return cancel function. Change-Id: I37c687c57a29d9f139c7fb648ce7de69093ed623 Reviewed-on: https://go-review.googlesource.com/c/50410 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
In some optimization rules the type of generated OffPtr was incorrectly set to the type of the pointee, instead of the pointer. When the OffPtr value is spilled, this may generate a spill of the wrong type, e.g. a floating point spill of an integer (pointer) value. On Wasm, this leads to invalid bytecode. Fixes #27961. Change-Id: I5d464847eb900ed90794105c0013a1a7330756cc Reviewed-on: https://go-review.googlesource.com/c/139257 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Richard Musiol <neelance@gmail.com>
-
Anton Gyllenberg authored
p = path.Dir(p) converges to either "." or "/". The current implementation of modload.QueryPackage() has a loop that terminates only on ".", not "/". This leads to the go command hanging in an infinite loop if the user manages to supply a file path starting with "/" as package path. An example of the issue is if the user (incorrectly) attempts to use an absolute directory path in an import statement within a module (import "/home/bob/myproj") and then runs go list. Fixes #27558 Change-Id: Iaa6a4f7b05eba30609373636e50224ae2e7d6158 GitHub-Last-Rev: 3a70d3a4277395c2dd8bb50f61b1ac3e44caee28 GitHub-Pull-Request: golang/go#27976 Reviewed-on: https://go-review.googlesource.com/c/139098 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Clément Chigot authored
This commit adds AIX operating system to cmd/dist package for ppc64 architecture. The stack guard is increased because of syscalls made inside the runtime which need a larger stack. Disable cmd/vet/all tests until aix/ppc64 is fully available. Change-Id: I7e3caf86724249ae564a152d90c1cbd4de288814 Reviewed-on: https://go-review.googlesource.com/c/138715 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Eduard Urbach authored
This will clarify that the resources are not completely pushed yet when `Push` returns and that it starts a separate goroutine. This might be implementation dependant but as I believe there is currently only one implementation it should be added to the documentation of the interface which most people will look up first. Change-Id: Id151c5563fd0c4e611eb1d93b4f64bf747ddf6d4 GitHub-Last-Rev: 1f46eb9a081f4529abc04026589ffd463be579b3 GitHub-Pull-Request: golang/go#25025 Reviewed-on: https://go-review.googlesource.com/c/108939Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Henderson authored
Change-Id: Ie7f6592d726eba73a5e6b3203e083bff55ff8e4e GitHub-Last-Rev: 4e317b39dd337f95aa7b7f321906e69a2c14b84e GitHub-Pull-Request: golang/go#27977 Reviewed-on: https://go-review.googlesource.com/c/139100Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ben Shi authored
In the arm assembler, "AMOVW" never falls into optab case 13, so the check "if p.As == AMOVW" is useless. Change-Id: Iec241d5b4cffb358a1477f470619dc9a6287884a Reviewed-on: https://go-review.googlesource.com/c/138575 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
- 02 Oct, 2018 1 commit
-
-
Brad Fitzpatrick authored
WebSockets requires HTTP/1 in practice (no spec or implementations work over HTTP/2), so if we get an HTTP request that looks like it's trying to initiate WebSockets, use HTTP/1, like browsers do. This is part of a series of commits to make WebSockets work over httputil.ReverseProxy. See #26937. Updates #26937 Change-Id: I6ad3df9b0a21fddf62fa7d9cacef48e7d5d9585b Reviewed-on: https://go-review.googlesource.com/c/137437 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-