- 07 Mar, 2017 17 commits
-
-
Daniel Martí authored
It's only ever called with the value it was using, but the code was counterintuitive. Use the parameter instead, like the other funcs near it. Found by github.com/mvdan/unparam. Change-Id: I45855e11d749380b9b2a28e6dd1d5dedf119a19b Reviewed-on: https://go-review.googlesource.com/37893Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Elias Naur authored
Using the stubs, user.Current will no longer fail on Android, fixing the os/exec.TestCredentialNoSetGroups test. Change-Id: I8b9842aa6704c0cde383c549a614bab0a0ed7695 Reviewed-on: https://go-review.googlesource.com/37765 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
When defining an int const, the compiler tries to cast the RHS expression to int. The cast may fail for three reasons: 1. expr is an integer constant that overflows int 2. expr is a floating point constant 3. expr is a complex constant, or not a number In the second case, in order to print a sensible error message, we must distinguish between a floating point constant that should be included in the error message and a floating point constant that cannot be reasonably formatted for inclusion in an error message. For example, in: const a int = 1.1 const b int = 1 + 1e-100 a is in the former group, while b is in the latter, since the floating point value resulting from the evaluation of the rhs of the assignment (1.00...01) is too long to be fully printed in an error message, and cannot be shortened without making the error message misleading (rounding or truncating it would result in a "1", which looks like an integer constant, and it makes little sense in an error message about an invalid floating point expression). To fix this problem, we try to format the float value using fconv (which is used by the error reporting mechanism to format float arguments), and then parse the resulting string back to a big.Float. If the result is an integer, we assume that expr is a float value that cannot be reasonably be formatted as a string, and we emit an error message that does not include its string representation. Also, change the error message for overflows to a more conservative "integer too large", which does not mention overflows that are only caused by an internal implementation restriction. Also, change (*Mpint) SetFloat so that it returns a bool (instead of 0/-1 for success/failure). Fixes #11371 Change-Id: Ibbc73e2ed2eaf41f07827b0649d0eb637150ecaa Reviewed-on: https://go-review.googlesource.com/35411 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
Instead of skipping them based on string matching much later in the compilation process, skip them up front using the proper API. Passes toolstash-check. Change-Id: Ibd4c0448a0701ba0de3235d4689ef300235fa1d9 Reviewed-on: https://go-review.googlesource.com/37930 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I90143e3c6e95a1495f300ffeb10de554aa41f56a Reviewed-on: https://go-review.googlesource.com/37889 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Elias Naur authored
Change-Id: I5f85a7980b9a18d3641c4ee8b0992671a8421bb0 Reviewed-on: https://go-review.googlesource.com/37896 Run-TryBot: Elias Naur <elias.naur@gmail.com> Reviewed-by:
-
Kevin Burke authored
Replace 'does not contains' with 'does not contain' where it appears in the source code. Change-Id: Ie7266347c429512c8a41a7e19142afca7ead3922 Reviewed-on: https://go-review.googlesource.com/37887Reviewed-by:
-
Hiroshi Ioka authored
Fixes #19416 Change-Id: I23c69ff637abaa202909f1cba6ed41b3cfe3d117 Reviewed-on: https://go-review.googlesource.com/37812Reviewed-by:
-
Matthew Dempsky authored
Passes toolstash -cmp. Change-Id: I4bd60f7ebba5457e7b3ece688fee2351bfeeb59a Reviewed-on: https://go-review.googlesource.com/37874 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alessandro Arzilli <alessandro.arzilli@gmail.com> Reviewed-by:
Than McIntosh <thanm@google.com>
-
Matthew Dempsky authored
No need to keep as Nodes when they're all Types anyway. Change-Id: I8157914ba5b09cadf2263247844680a60233a0f2 Reviewed-on: https://go-review.googlesource.com/37886 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Andrew Benton authored
For consistency with the other named types in this package, this change renames the unexported rsaPublicKey struct to pkcs1PublicKey and positions the declaration up with the other similarly-named types in pkcs1.go. See the final comment of #19355 for discussion. Change-Id: I1fa0366a8efa01602b81bc69287ef747abce84f5 Reviewed-on: https://go-review.googlesource.com/37885Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: I4795dd0221784d10cf7c9f7b84ea00787d5789f2 Reviewed-on: https://go-review.googlesource.com/37892Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
Sometimes asm code in 2 different packages name its global symbols with the same name. When these symbols are passed to gcc, it refuses to link them thinking they are duplicate. Mark these symbols with IMAGE_SYM_CLASS_STATIC. Fixes #19198. Change-Id: Ia5f59ede47354a2b48ce60b7d406c9f097ff2000 Reviewed-on: https://go-review.googlesource.com/37810Reviewed-by:
-
Hiroshi Ioka authored
rfc2047 says: White space between adjacent 'encoded-word's is not displayed. Although, mime package already have that feature, we cannot simply reuse that code, because there is a subtle difference in quoted-string handling. Fixes #19363 Change-Id: I754201aa3c6b701074ad78fe46818af5b96cbd00 Reviewed-on: https://go-review.googlesource.com/37811Reviewed-by:
-
Josselin Costanzi authored
Document and check that the alphabet cannot contain '\n' or '\r'. Document that the alphabet cannot contain the padding character. Document that the padding character must be equal or bellow '\xff'. Document that the padding character must not be '\n' or '\r'. Fixes #19343 Fixes #19318 Change-Id: I6de0034d347ffdf317d7ea55d6fe38b01c2c4c03 Reviewed-on: https://go-review.googlesource.com/37838Reviewed-by:
-
Michael Munday authored
Should fix the build dashboard. Change-Id: Id4c8a996d9f689e1fa865a9cff9a7f52c700c691 Reviewed-on: https://go-review.googlesource.com/37877 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jaana Burcu Dogan authored
Change-Id: I4718c82540ef214728393824b89c8c7f6656823b Reviewed-on: https://go-review.googlesource.com/36210Reviewed-by:
-
- 06 Mar, 2017 23 commits
-
-
Robert Griesemer authored
This reverts commit cb6e0639. The fix is incorrect as it's perfectly fine to refer to an identifier 'init' inside a function, and 'init' may even be a variable of function value. Misspelling 'init' in that context would lead to an incorrect error message. Reopened #8481. Change-Id: I49787fdf7738213370ae6f0cab54013e9e3394a8 Reviewed-on: https://go-review.googlesource.com/37876 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
philhofer authored
Given (Store [c] (OffPtr <T1> [0] (Addr <T> _)) _ (Store [c] (Addr <T> _) _ _)) dead store elimination doesn't eliminate the inner Store, because it addresses a type of a different width than the first store. When decomposing StructMake operations, always generate an OffPtr to address struct fields so that dead stores to the first field of the struct can be optimized away. benchmarks affected on darwin/amd64: HTTPClientServer-8 73.2µs ± 1% 72.7µs ± 1% -0.69% (p=0.022 n=9+10) TimeParse-8 304ns ± 1% 300ns ± 0% -1.61% (p=0.000 n=9+9) RegexpMatchEasy1_32-8 80.1ns ± 0% 79.5ns ± 1% -0.84% (p=0.000 n=8+9) GobDecode-8 6.78ms ± 0% 6.81ms ± 1% +0.46% (p=0.000 n=9+10) Gunzip-8 36.1ms ± 1% 36.2ms ± 0% +0.37% (p=0.019 n=10+10) JSONEncode-8 15.6ms ± 0% 15.7ms ± 0% +0.69% (p=0.000 n=9+10) Change-Id: Ia80d73fd047f9400c616ca64fdee4f438a0e7f21 Reviewed-on: https://go-review.googlesource.com/37769 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Keith Randall <khr@golang.org>
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: I66f5a191cf9c9a11a7c3c4d7ee0a02e2c185f019 Reviewed-on: https://go-review.googlesource.com/37841Reviewed-by:
-
Robert Griesemer authored
Debugging support. Change-Id: Ia518aaed36eaba76e6233306f718ad8aff3ce744 Reviewed-on: https://go-review.googlesource.com/37875Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I402383e893223facae451adbd640113126d5edd9 Reviewed-on: https://go-review.googlesource.com/37873 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Shrinks LSym somewhat for non-STEXT LSyms, which are much more common. While here, switch to tracking Automs in a slice instead of a linked list. (Previously, this would have made LSyms larger.) Passes toolstash-check. Change-Id: I082e50e1d1f1b544c9e06b6e412a186be6a4a2b5 Reviewed-on: https://go-review.googlesource.com/37872Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Matthew Dempsky authored
Instead, cmd/compile can directly emit R_USEFIELD relocations. Manually verified rsc.io/tmp/fieldtrack still passes. Change-Id: Ib1fb5ab902ff0ad17ef6a862a9a5692caf7f87d1 Reviewed-on: https://go-review.googlesource.com/37871 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
By clearing out t.nod in copytype, we effectively lose the reference from a Type back to its declaring OTYPE Node. This means later in typenamesym when we add typenod(t) to signatlist, we end up creating a new OTYPE Node. Moreover, this Node's position information will depend on whatever context it happens be needed, and will be used for the Type's position in the export data. Updates #19391. Change-Id: Ied93126449f75d7c5e3275cbdcc6fa657a8aa21d Reviewed-on: https://go-review.googlesource.com/37870 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Quentin Smith authored
Change-Id: Ie52dac8eb4daed95e049ad74d5ae101e8a5cb854 Reviewed-on: https://go-review.googlesource.com/37725 Run-TryBot: Quentin Smith <quentin@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Austin Clements authored
For historical reasons, it's still commonplace to iterate over the slice returned by runtime.Callers and call FuncForPC on each PC. This is broken in gccgo and somewhat broken in gc and will become more broken in gc with mid-stack inlining. In Go 1.7, we introduced runtime.CallersFrames to deal with these problems, but didn't strongly direct people toward using it. Reword the documentation on runtime.Callers to more strongly encourage people to use CallersFrames and explicitly discourage them from iterating over the PCs or using FuncForPC on the results. Fixes #19426. Change-Id: Id0d14cb51a0e9521c8fdde9612610f2c2b9383c4 Reviewed-on: https://go-review.googlesource.com/37726Reviewed-by:
-
Daniel Martí authored
We're passed a pkg, so it makes little sense to not use it. This was probably a typo and not the intended behaviour. Fixes #19407. Change-Id: Ia1c9130c0e474daf47753cf51914a2d7db272c96 Reviewed-on: https://go-review.googlesource.com/37839Reviewed-by:
-
Ian Lance Taylor authored
We don't need to start the goroutines if the program isn't going to do any I/O. Fixes #19390. Change-Id: I47eef992d3ad05ed5f3150f4d6e5b3e0cb16a551 Reviewed-on: https://go-review.googlesource.com/37762 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com>
-
Josselin Costanzi authored
Fix Decode to return the correct illegal data index from a corrupted input that contains whitespaces. Fixes #19406 Change-Id: Ib2b2b6ed7e41f024d0da2bd035caec4317c2869c Reviewed-on: https://go-review.googlesource.com/37837Reviewed-by:
-
Austin Clements authored
Currently almost every function that deals with a *_func has to first look up the *moduledata for the module containing the function's entry point. This means we almost always do at least two identical module lookups whenever we deal with a *_func (one to get the *_func and another to get something from its module data) and sometimes several more. Fix this by making findfunc return a new funcInfo type that embeds *_func, but also includes the *moduledata, and making all of the functions that currently take a *_func instead take a funcInfo and use the already-found *moduledata. This transformation is trivial for the most part, since the *_func type is usually inferred. The annoying part is that we can no longer use nil to indicate failure, so this introduces a funcInfo.valid() method and replaces nil checks with calls to valid. Change-Id: I9b8075ef1c31185c1943596d96dec45c7ab5100f Reviewed-on: https://go-review.googlesource.com/37331 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Matthew Dempsky authored
Updates the disassembler to support the same object file version used by the assembler and linker. Related #14782. Change-Id: I4cd7560c4e4e1350cfb27ca9cbe0fde25fe693cc Reviewed-on: https://go-review.googlesource.com/37797 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Matthew Dempsky authored
golang.org/cl/37231 changed the object file format, but forgot to bump the version string. Change-Id: I8351ec8ed55e65479006e7c0df20254d0e31015f Reviewed-on: https://go-review.googlesource.com/37798 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: I186d2afd067e97eb05d65c4599119b347f82867d Reviewed-on: https://go-review.googlesource.com/37840Reviewed-by:
-
Robert Griesemer authored
For #16088. Change-Id: Ib38bda06a5c5d110ca86510043775c5cf229e6a8 Reviewed-on: https://go-review.googlesource.com/37756Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
For #16088. Change-Id: I0ff480e95ef5af375be2ccc655f8b233a7bcd39d Reviewed-on: https://go-review.googlesource.com/37755Reviewed-by:
-
Robert Griesemer authored
This will make type-checking more robust in the presence of import errors. Also: - import is now relative to directory containing teh file containing the import (matters for relative imports) - factored out package import code from main resolver loop - fixed a couple of minor bugs Fixes #16088. Change-Id: I1ace45c13cd0fa675d1762877cec0a30afd9ecdc Reviewed-on: https://go-review.googlesource.com/37697 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
-
Austin Clements authored
Currently we acquire a global lock for every newMarkBits call. This is unfortunate since every span sweep operation calls newMarkBits. However, most allocations are simply linear allocations from the current arena. Take advantage of this to add a lock-free fast path for allocating from the current arena. With this change, the global lock only protects the lists of arenas, not the free offset in the current arena. Change-Id: I6cf6182af8492c8bfc21276114c77275fe3d7826 Reviewed-on: https://go-review.googlesource.com/34595 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently, newArena holds the gcBitsArenas lock across allocating memory from the OS for a new gcBits arena. This is a global lock and allocating physical memory can be expensive, so this has the potential to cause high lock contention, especially since every single span sweep operation calls newArena (via newMarkBits). Improve the situation by temporarily dropping the lock across allocation. This means the caller now has to revalidate its assumptions after the lock is dropped, so this also factors out that code path and reinvokes it after the lock is acquired. Change-Id: I1113200a954ab4aad16b5071512583cfac744bdc Reviewed-on: https://go-review.googlesource.com/34594 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Josh Bleecher Snyder authored
We generate a lot of pointless dead blocks during the AST to SSA conversion. There are a few commonly occurring kinds of statements that contain neither variables nor code and that switch to a new block themselves. Stop making dead blocks for them. For the code in #19379, this reduces compilation wall time by 36% and max rss by 28%. This also helps a little for regular code, particularly code heavy on switch statements. name old time/op new time/op delta Template 231ms ± 3% 230ms ± 5% ~ (p=0.402 n=17+16) Unicode 101ms ± 4% 103ms ± 5% ~ (p=0.221 n=19+18) GoTypes 635ms ± 5% 625ms ± 4% ~ (p=0.063 n=20+18) Compiler 2.93s ± 2% 2.89s ± 2% -1.22% (p=0.003 n=20+19) SSA 4.53s ± 3% 4.52s ± 3% ~ (p=0.380 n=20+19) Flate 132ms ± 4% 133ms ± 5% ~ (p=0.647 n=20+19) GoParser 161ms ± 3% 161ms ± 4% ~ (p=0.749 n=20+19) Reflect 403ms ± 4% 397ms ± 3% -1.53% (p=0.030 n=20+19) Tar 121ms ± 2% 121ms ± 8% ~ (p=0.544 n=19+19) XML 225ms ± 3% 224ms ± 4% ~ (p=0.396 n=20+19) name old user-ns/op new user-ns/op delta Template 302user-ms ± 1% 297user-ms ± 7% -1.49% (p=0.048 n=15+18) Unicode 142user-ms ± 3% 143user-ms ± 5% ~ (p=0.363 n=19+17) GoTypes 852user-ms ± 5% 851user-ms ± 3% ~ (p=0.851 n=20+18) Compiler 4.11user-s ± 6% 3.98user-s ± 3% -3.08% (p=0.000 n=20+19) SSA 6.91user-s ± 5% 6.82user-s ± 7% ~ (p=0.113 n=20+19) Flate 164user-ms ± 4% 168user-ms ± 4% +2.42% (p=0.001 n=18+19) GoParser 207user-ms ± 4% 206user-ms ± 4% ~ (p=0.176 n=20+18) Reflect 509user-ms ± 4% 505user-ms ± 4% ~ (p=0.113 n=20+19) Tar 153user-ms ± 7% 151user-ms ± 9% ~ (p=0.283 n=20+19) XML 284user-ms ± 4% 282user-ms ± 4% ~ (p=0.270 n=20+19) name old alloc/op new alloc/op delta Template 42.6MB ± 0% 41.9MB ± 0% -1.55% (p=0.000 n=19+19) Unicode 31.7MB ± 0% 31.7MB ± 0% ~ (p=0.828 n=20+18) GoTypes 124MB ± 0% 121MB ± 0% -2.11% (p=0.000 n=20+17) Compiler 534MB ± 0% 523MB ± 0% -2.06% (p=0.000 n=20+19) SSA 989MB ± 0% 977MB ± 0% -1.28% (p=0.000 n=20+19) Flate 27.8MB ± 0% 27.5MB ± 0% -0.98% (p=0.000 n=20+19) GoParser 34.3MB ± 0% 34.0MB ± 0% -0.81% (p=0.000 n=20+19) Reflect 84.6MB ± 0% 82.9MB ± 0% -2.00% (p=0.000 n=17+18) Tar 28.8MB ± 0% 28.3MB ± 0% -1.52% (p=0.000 n=16+18) XML 47.2MB ± 0% 45.8MB ± 0% -2.99% (p=0.000 n=20+19) name old allocs/op new allocs/op delta Template 421k ± 1% 419k ± 1% -0.41% (p=0.001 n=20+19) Unicode 338k ± 1% 338k ± 1% ~ (p=0.478 n=20+19) GoTypes 1.28M ± 0% 1.28M ± 0% -0.36% (p=0.000 n=20+18) Compiler 5.06M ± 0% 5.03M ± 0% -0.63% (p=0.000 n=20+19) SSA 9.14M ± 0% 9.11M ± 0% -0.34% (p=0.000 n=20+19) Flate 267k ± 1% 266k ± 1% ~ (p=0.149 n=20+19) GoParser 347k ± 0% 347k ± 1% ~ (p=0.103 n=19+19) Reflect 1.07M ± 0% 1.07M ± 0% -0.42% (p=0.000 n=16+18) Tar 274k ± 0% 273k ± 1% ~ (p=0.116 n=19+19) XML 449k ± 0% 446k ± 1% -0.60% (p=0.000 n=20+19) Updates #19379 Change-Id: Ie798c347a0c081f5e349e1529880bebaae290967 Reviewed-on: https://go-review.googlesource.com/37760Reviewed-by:
David Chase <drchase@google.com>
-
