- 13 Oct, 2016 17 commits
-
-
Russ Cox authored
No functional changes here. Just makes next CL easier to read. Change-Id: Icf7b2281b4da6cb59ff4edff05943b2ee288576a Reviewed-on: https://go-review.googlesource.com/30945 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Anthony Canino authored
"abc"[1] is not like 'b', in that -"abc"[1] is uint8 math, not ideal constant math. Delay the constantification until after ideal constant folding is over. Fixes #11370. Change-Id: Iba2fc00ca2455959e7bab8f4b8b4aac14b1f9858 Reviewed-on: https://go-review.googlesource.com/15740 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Fixes #15146. Change-Id: I229611b9cc995a1391681c492c4d742195c787ea Reviewed-on: https://go-review.googlesource.com/30943 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
When we need to generate a call to _cgoCheckPointer, we need to type assert the result back to the desired type. That is harder when the type is unsafe.Pointer, as the package can have values of unsafe.Pointer types without actually importing unsafe, by mixing C void* and :=. We used to handle this by generating a special function for each needed type, and defining that function in a separate file where we did import unsafe. Simplify the code by not generating those functions, but instead just import unsafe under the alias _cgo_unsafe. This is a simplification step toward a fix for issue #16591. Change-Id: I0edb3e04b6400ca068751709fe063397cf960a54 Reviewed-on: https://go-review.googlesource.com/30973 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
name old time/op new time/op delta Template 349ms ± 5% 339ms ± 7% -2.89% (p=0.000 n=27+29) Unicode 187ms ±11% 182ms ±11% -2.77% (p=0.039 n=29+29) GoTypes 1.05s ± 3% 1.04s ± 4% ~ (p=0.103 n=29+29) Compiler 4.57s ± 3% 4.55s ± 3% ~ (p=0.202 n=30+29) name old user-ns/op new user-ns/op delta Template 510M ±21% 521M ±18% ~ (p=0.281 n=30+29) Unicode 303M ±34% 300M ±28% ~ (p=0.592 n=30+30) GoTypes 1.52G ± 9% 1.50G ± 9% ~ (p=0.314 n=30+30) Compiler 6.50G ± 5% 6.44G ± 5% ~ (p=0.362 n=29+30) name old alloc/op new alloc/op delta Template 44.7MB ± 0% 44.0MB ± 0% -1.63% (p=0.000 n=28+28) Unicode 34.6MB ± 0% 34.5MB ± 0% -0.18% (p=0.000 n=30+29) GoTypes 125MB ± 0% 123MB ± 0% -1.14% (p=0.000 n=30+30) Compiler 515MB ± 0% 513MB ± 0% -0.52% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 427k ± 0% 416k ± 0% -2.66% (p=0.000 n=30+30) Unicode 323k ± 0% 322k ± 0% -0.28% (p=0.000 n=30+30) GoTypes 1.21M ± 0% 1.18M ± 0% -1.84% (p=0.000 n=29+30) Compiler 4.40M ± 0% 4.36M ± 0% -0.95% (p=0.000 n=30+30) Passes toolstash -cmp. Change-Id: Ifee7d012b1cddadda01450e027eef8d4ecf5581f Reviewed-on: https://go-review.googlesource.com/30980 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I36cf3523e00b80e2d3a690f251edd5d6f665d156 Reviewed-on: https://go-review.googlesource.com/30975 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Previously, we used OKEY nodes to represent keyed struct literal elements. The field names were represented by an ONAME node, but this is clumsy because it's the only remaining case where ONAME was used to represent a bare identifier and not a variable. This CL introduces a new OSTRUCTKEY node op for use in struct literals. These ops instead store the field name in the node's own Sym field. This is similar in spirit to golang.org/cl/20890. Significant reduction in allocations for struct literal heavy code like package unicode: name old time/op new time/op delta Template 345ms ± 6% 341ms ± 6% ~ (p=0.141 n=29+28) Unicode 200ms ± 9% 184ms ± 7% -7.77% (p=0.000 n=29+30) GoTypes 1.04s ± 3% 1.05s ± 3% ~ (p=0.096 n=30+30) Compiler 4.47s ± 9% 4.49s ± 6% ~ (p=0.890 n=29+29) name old user-ns/op new user-ns/op delta Template 523M ±13% 516M ±17% ~ (p=0.400 n=29+30) Unicode 334M ±27% 314M ±30% ~ (p=0.093 n=30+30) GoTypes 1.53G ±10% 1.52G ±10% ~ (p=0.572 n=30+30) Compiler 6.28G ± 7% 6.34G ±11% ~ (p=0.300 n=30+30) name old alloc/op new alloc/op delta Template 44.5MB ± 0% 44.4MB ± 0% -0.35% (p=0.000 n=27+30) Unicode 39.2MB ± 0% 34.5MB ± 0% -11.79% (p=0.000 n=26+30) GoTypes 125MB ± 0% 125MB ± 0% -0.12% (p=0.000 n=29+30) Compiler 515MB ± 0% 515MB ± 0% -0.10% (p=0.000 n=29+30) name old allocs/op new allocs/op delta Template 426k ± 0% 424k ± 0% -0.39% (p=0.000 n=29+30) Unicode 374k ± 0% 323k ± 0% -13.67% (p=0.000 n=29+30) GoTypes 1.21M ± 0% 1.21M ± 0% -0.14% (p=0.000 n=29+29) Compiler 4.40M ± 0% 4.39M ± 0% -0.13% (p=0.000 n=29+30) Passes toolstash/buildall. Change-Id: Iba4ee765dd1748f67e52fcade1cd75c9f6e13fa9 Reviewed-on: https://go-review.googlesource.com/30974 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
aindex is overkill when it's only ever used with known integer constants, so just use typArray directly instead. Change-Id: I43fc14e604172df859b3ad9d848d219bbe48e434 Reviewed-on: https://go-review.googlesource.com/30979 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alex Brainman authored
This CL introduces first test for readConsole. And new test discovered couple of problems with readConsole. Console characters consist of multiple bytes each, but byte blocks returned by syscall.ReadFile have no character boundaries. Some multi-byte characters might start at the end of one block, and end at the start of next block. readConsole feeds these blocks to syscall.MultiByteToWideChar to convert them into utf16, but if some multi-byte characters have no ending or starting bytes, the syscall.MultiByteToWideChar might get confused. Current version of syscall.MultiByteToWideChar call will make syscall.MultiByteToWideChar ignore all these not complete multi-byte characters. The CL solves this issue by changing processing from "randomly sized block of bytes at a time" to "one multi-byte character at a time". New readConsole code calls syscall.ReadFile to get 1 byte first. Then it feeds this byte to syscall.MultiByteToWideChar. The new syscall.MultiByteToWideChar call uses MB_ERR_INVALID_CHARS flag to make syscall.MultiByteToWideChar return error if input is not complete character. If syscall.MultiByteToWideChar returns correspondent error, we read another byte and pass 2 byte buffer into syscall.MultiByteToWideChar, and so on until success. Old readConsole code would also sometimes return no data if user buffer was smaller then uint16 size, which would confuse callers that supply 1 byte buffer. This CL fixes that problem too. Fixes #17097 Change-Id: I88136cdf6a7bf3aed5fbb9ad2c759b6c0304ce30 Reviewed-on: https://go-review.googlesource.com/29493 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Hiroshi Ioka authored
* convert important functions to methods * rename EscXXX to XXX in NodeEscState * rename local variables more friendly * simplify redundant code * update comments Change-Id: I8442bf4f8dde84523d9a2ad3d04b1cd326bd4719 Reviewed-on: https://go-review.googlesource.com/30893 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Alex Browne authored
It is easy to make the mistake of duplicating json struct field tags especially when copy/pasting. This commit causes go vet to report the mistake. Only field tags in the same struct type are considered, because that is the only case which is undoubtedly an error. Fixes #12791. Change-Id: I4130e4c04b177694cc0daf8f1acaf0751d4f062b Reviewed-on: https://go-review.googlesource.com/16704 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Pratt authored
Change-Id: Iafc392ba06452419542ec85e91d44991839eb6f8 Reviewed-on: https://go-review.googlesource.com/19593 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Shenghou Ma authored
Fixes #9039. Change-Id: I7d213b4f8e4cda73ea7687fb97dbd22e58163949 Reviewed-on: https://go-review.googlesource.com/9683 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Shenghou Ma authored
Change-Id: I7d213b4f8e4cda73ea7687fb97dbd22e58163948 Reviewed-on: https://go-review.googlesource.com/9682 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
For #9039. Change-Id: I2b1bcd76857ff332411ca21a0cc5def3097a8eaf Reviewed-on: https://go-review.googlesource.com/30936 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Allan Simon authored
There was an inconsistency between the (json encoding + documentation) and the xml encoding implementation. Pointer to an empty value was not being serialized (i.e simply ignored). Which had the effect of making impossible to have a struct with a string field for which we wanted to serialize the value "" Fixes #5452 Change-Id: Id858701801158409be01e962d2cda843424bd22a Reviewed-on: https://go-review.googlesource.com/15684Reviewed-by:
-
Xia Bin authored
Gccgo isn't locking the OS thread properly during calls. Change-Id: Idb2475291405e390cbb83abb27a402fd0381d0c4 Reviewed-on: https://go-review.googlesource.com/18882 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 12 Oct, 2016 23 commits
-
-
Russ Cox authored
Change-Id: I74f47f519dfee10cd079ad9a4e09e36e8d74c6dc Reviewed-on: https://go-review.googlesource.com/30937 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
Change-Id: I9ddb7d2a97d28aba7a107b65f278993daf7807fa Reviewed-on: https://go-review.googlesource.com/30960Reviewed-by:
-
Lynn Boger authored
Some of the branch instructions (BEQ, BNE, BLT, etc.) accept all the valid CR values as operands, but the CR register value is not parsed and not put into the instruction, so that CR0 is always used regardless of what was specified on the instruction. For example BEQ CR2,label becomes beq cr0,label. This adds the change to the PPC64 assembler to recognize the CR value and set the approppriate field in the instruction so the correct CR is used. This also adds some general comments on the branch instruction BC and its operand values. Fixes #17408 Change-Id: I8e956372a42846a4c09a7259e9172eaa29118e71 Reviewed-on: https://go-review.googlesource.com/30930 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
To compile: m[k] = v instead of: mapassign(maptype, m, &k, &v), do do: *mapassign(maptype, m, &k) = v mapassign returns a pointer to the value slot in the map. It is just like mapaccess except that it will allocate a new slot if k is not already present in the map. This makes map accesses faster but potentially larger (codewise). It is faster because the write into the map is done when the compiler knows the concrete type, so it can be done with a few store instructions instead of calling typedmemmove. We also potentially avoid stack temporaries to hold v. The code can be larger when the map has pointers in its value type, since there is a write barrier call in addition to the mapassign call. That makes the code at the callsite a bit bigger (go binary is 0.3% bigger). This CL is in preparation for doing operations like m[k] += v with only a single runtime call. That will roughly double the speed of such operations. Update #17133 Update #5147 Change-Id: Ia435f032090a2ed905dac9234e693972fe8c2dc5 Reviewed-on: https://go-review.googlesource.com/30815 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Functions like ToLower and ToUpper return the invalid rune back, so we might as well do the same here. I changed my mind about panicking when I tried to document the behavior. Fixes #16690 (again). Change-Id: If1c68bfcd66daea160fd19948e7672b0e1add106 Reviewed-on: https://go-review.googlesource.com/30935 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
David Crawshaw authored
Fixes #17415 Change-Id: I6f896d549092e5e0dba72351e5385992b4cbe90f Reviewed-on: https://go-review.googlesource.com/30933 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Adam Langley authored
Since this changes the offered curves in the ClientHello, all the test data needs to be updated too. Change-Id: I227934711104349c0f0eab11d854e5a2adcbc363 Reviewed-on: https://go-review.googlesource.com/30825Reviewed-by:
-
Adam Langley authored
X25519 (RFC 7748) is now commonly used for key agreement in TLS connections, as specified in https://tools.ietf.org/html/draft-ietf-tls-curve25519-01. This change adds support for that in crypto/tls, but does not enabled it by default so that there's less test noise. A future change will enable it by default and will update all the test data at the same time. Change-Id: I91802ecd776d73aae5c65bcb653d12e23c413ed4 Reviewed-on: https://go-review.googlesource.com/30824Reviewed-by:
-
Adam Langley authored
When updating the test data against OpenSSL, the handshake can fail and the stdout/stderr output of OpenSSL is very useful in finding out why. However, printing that output has been broken for some time because its no longer sent to a byte.Buffer. This change fixes that. Change-Id: I6f846c7dc80f1ccee9fa1be36f0b579b3754e05f Reviewed-on: https://go-review.googlesource.com/30823Reviewed-by:
-
Adam Langley authored
This change imports the curve25519 package from x/crypto at revision 594708b89f21ece706681be23d04a6513a22de6e. Change-Id: I379eaa71492959e404259fc1273d0057573bc243 Reviewed-on: https://go-review.googlesource.com/30822Reviewed-by:
-
Adam Langley authored
We will need OpenSSL 1.1.0 in order to test some of the features expected for Go 1.8. However, 1.1.0 also disables (by default) some things that we still want to test, such as RC4, 3DES and SSLv3. Thus developers wanting to update the crypto/tls test data will need to build OpenSSL from source. This change updates the test data with transcripts generated by 1.1.0 (in order to reduce future diffs) and also causes a banner to be printed if 1.1.0 is not used when updating. (The test for an ALPN mismatch is removed because OpenSSL now terminates the connection with a fatal alert if no known ALPN protocols are offered. There's no point testing against this because it's an OpenSSL behaviour.) Change-Id: I957516975e0b8c7def84184f65c81d0b68f1c551 Reviewed-on: https://go-review.googlesource.com/30821 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
* Assert that the format is GNU. Both GNU and STAR have some form of sparse file support with incompatible header structures. Worse yet, both formats use the 'S' type flag to indicate the presence of a sparse file. As such, we should check the format (based on magic numbers) and fail early. * Move realsize parsing logic into readOldGNUSparseMap. This is related to the sparse parsing logic and belongs here. * Fix the termination condition for parsing sparse fields. The termination condition for reading the sparse fields is to simply check if the first byte of the offset field is NULL. This does not seem to be documented in the GNU manual, but this is the check done by the both the GNU and BSD implementations: http://git.savannah.gnu.org/cgit/tar.git/tree/src/sparse.c?id=9a33077a7b7ad7d32815a21dee54eba63b38a81c#n731 https://github.com/libarchive/libarchive/blob/1fa9c7bf90f0862036a99896b0501c381584451a/libarchive/archive_read_support_format_tar.c#L2207 * Fix the parsing of sparse fields to use parseNumeric. This is what GNU and BSD do. The previous two links show that GNU and BSD both handle base-256 and base-8. * Detect truncated streams. The call to io.ReadFull does not check if the error is io.EOF. Getting io.EOF in this method is never okay and should always be converted to io.ErrUnexpectedEOF. * Simplify the function. The logic is essentially a do-while loop so we can remove some redundant code. Change-Id: Ib2f601b1a283eaec1e41b1d3396d649c80749c4e Reviewed-on: https://go-review.googlesource.com/28471Reviewed-by:
-
Joe Tsai authored
Most calls to strconv.ParseInt(x, 10, 0) should really be calls to strconv.ParseInt(x, 10, 64) in order to ensure that they do not overflow on 32b architectures. Furthermore, we should document a bug where Uid and Gid may overflow on 32b machines since the type is declared as int. Change-Id: I99c0670b3c2922e4a9806822d9ad37e1a364b2b8 Reviewed-on: https://go-review.googlesource.com/28472 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Hiroshi Ioka authored
Fixes #16690 Change-Id: I6db588c4b0f23c5ec6bc9b85a488b60fab3f2f13 Reviewed-on: https://go-review.googlesource.com/30892Reviewed-by:
-
Momchil Velikov authored
- trim blocks with multiple predecessors - trim blocks, which contain only phi-functions - trim blocks, which can be merged into the successor block As an example, compiling the following source: ---8<------ package p type Node struct { Key int Left, Right *Node } func Search(r *Node, k int) *Node { for r != nil { switch { case k == r.Key: return r case k < r.Key: r = r.Left default: r = r.Right } } return nil } ---8<------ with `GOSSAFUNC=Search" go tool compile t.go`, results in the following code: ---8<------ genssa 00000 (t.go:8) TEXT "".Search(SB), $0 00001 (t.go:8) FUNCDATA $0, "".gcargs·0(SB) 00002 (t.go:8) FUNCDATA $1, "".gclocals·1(SB) 00003 (t.go:8) TYPE "".r(FP)type.*"".Node, $8 00004 (t.go:8) TYPE "".k+8(FP)type.int, $8 00005 (t.go:8) TYPE "".~r2+16(FP)type.*"".Node, $8 v40 00006 (t.go:9) MOVQ "".k+8(FP), AX v34 00007 (t.go:9) MOVQ "".r(FP), CX v33 00008 (t.go:9) TESTQ CX, CX b2 00009 (t.go:9) JEQ $0, 22 v16 00010 (t.go:11) MOVQ (CX), DX v21 00011 (t.go:11) CMPQ DX, AX b9 00012 (t.go:11) JEQ $0, 19 v64 00013 (t.go:13) CMPQ AX, DX b13 00014 (t.go:13) JGE 17 v36 00015 (t.go:14) MOVQ 8(CX), CX b4 00016 (t.go:9) JMP 8 <---+ v42 00017 (t.go:16) MOVQ 16(CX), CX | b21 00018 (t.go:10) JMP 16 ----+ v28 00019 (t.go:12) VARDEF "".~r2+16(FP) v29 00020 (t.go:12) MOVQ CX, "".~r2+16(FP) b10 00021 (t.go:12) RET v44 00022 (t.go:19) VARDEF "".~r2+16(FP) v45 00023 (t.go:19) MOVQ $0, "".~r2+16(FP) b5 00024 (t.go:19) RET 00025 (<unknown line number>) END ---8<------ Note the jump at 18 jumps to another jump at 16. Looking at the function after trimming: --8<------ after trim [199 ns] b1: v1 = InitMem <mem> v2 = SP <uintptr> : SP v67 = Arg <*Node> {r} : r[*Node] v59 = Arg <int> {k} : k[int] v40 = LoadReg <int> v59 : AX v34 = LoadReg <*Node> v67 : CX Plain → b2 b2: ← b1 b4 v8 = Phi <*Node> v34 v68 : CX v33 = TESTQ <flags> v8 v8 NE v33 → b9 b5 (likely) b9: ← b2 v16 = MOVQload <int> v8 v1 : DX v21 = CMPQ <flags> v16 v40 EQ v21 → b10 b13 (unlikely) b13: ← b9 v64 = CMPQ <flags> v40 v16 LT v64 → b19 b21 b19: ← b13 v36 = MOVQload <*Node> [8] v8 v1 : CX Plain → b4 b4: ← b21 b19 < v68 = Phi <*Node> v42 v36 : CX <- no actual code Plain → b2 < b21: ← b13 v42 = MOVQload <*Node> [16] v8 v1 : CX Plain → b4 b10: ← b9 v28 = VarDef <mem> {~r2} v1 v29 = MOVQstore <mem> {~r2} v2 v8 v28 v30 = Copy <mem> v29 Ret v30 b5: ← b2 v44 = VarDef <mem> {~r2} v1 v45 = MOVQstoreconst <mem> {~r2} [val=0,off=0] v2 v44 v47 = Copy <mem> v45 Ret v47 --8<------ The jump at 16 corresponds to the edge b21 -> b4. The block b4 contains only phi-ops, i.e. no actual code besides the jump to b2. However b4 is not trimmed, because it a) has more than one predecessor, and b) it is not empty. This change enhances trim.go to remove more blocks, subject to the following criteria: - block has predecessors (i.e. not the start block) - block is BlockPlain - block does not loop back to itself - block is the single predecessor of its successor; the instructions of the block are merged into the successor - block does no emit actual code, besides a possible unconditional jump. Currently only OpPhi are considered to not be actual code, perhaps OpKeepAlive/others should be considered too? As an example, after the change, the block b4 is trimmed and the jump at 18 jumps directly to 8. Revision 1: Adjust phi-ops arguments after merge Ensure the number of phi-ops arguments matches the new number of predecessors in the merged block. When moving values, make them refer to the merged block. Revision 2: - Make clear the intent that we do not want to trim the entry block - Double check that we are merging a phi operation - Minor code style fix - Fix a potentially dangerous situation when a blocks refers to the inline value space in another block Change-Id: I0ab91779f931f404d11008f5c45606d985d7fbaa Reviewed-on: https://go-review.googlesource.com/28812 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Keith Randall <khr@golang.org>
-
Kevin Burke authored
Change-Id: I611511434f37c75f77c22f61f469108243bc0101 Reviewed-on: https://go-review.googlesource.com/29121Reviewed-by:
-
Cyrill Schumacher authored
- precalculate *Cookie slice in read cookie functions - readSetCookies: pre-allocs depending on the count of Set-Cookies - rename success variable to ok; avoid else - refactor Cookie.String to use less allocations - remove fmt package and replace with writes to a bytes.Buffer - add BenchmarkReadSetCookies and BenchmarkReadCookies name old time/op new time/op delta CookieString-8 1.42µs ± 2% 0.78µs ± 1% -45.36% (p=0.000 n=10+10) ReadSetCookies-8 3.46µs ± 1% 3.42µs ± 2% -1.39% (p=0.001 n=10+10) ReadCookies-8 5.12µs ± 1% 5.15µs ± 2% ~ (p=0.393 n=10+10) name old alloc/op new alloc/op delta CookieString-8 520B ± 0% 384B ± 0% -26.15% (p=0.000 n=10+10) ReadSetCookies-8 968B ± 0% 960B ± 0% -0.83% (p=0.000 n=10+10) ReadCookies-8 2.01kB ± 0% 2.01kB ± 0% ~ (all samples are equal) name old allocs/op new allocs/op delta CookieString-8 10.0 ± 0% 3.0 ± 0% -70.00% (p=0.000 n=10+10) ReadSetCookies-8 18.0 ± 0% 17.0 ± 0% -5.56% (p=0.000 n=10+10) ReadCookies-8 16.0 ± 0% 16.0 ± 0% ~ (all samples are equal) Change-Id: I870670987f10f3e52f9c657cfb8e6eaaa97a6162 Reviewed-on: https://go-review.googlesource.com/27850 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Alan Donovan authored
Change-Id: Ibcf5e0ba694b280744a00c2c6fda300f0a653455 Reviewed-on: https://go-review.googlesource.com/30715Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Alan Donovan authored
Change-Id: Ieb3d605f03a7185a707621bef7160090c9bdb51f Reviewed-on: https://go-review.googlesource.com/28873Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Emmanuel Odeke authored
Update comments for duffzero and duffcopy which referred to legacy locations: + cmd/?g/cgen.go + cmd/?g/ggen.go Remnants of the old days when we had 5g, 6g etc. Those locations have since moved to: + cmd/compile/internal/<arch>/cgen.go + cmd/compile/internal/<arch>/ggen.go Change-Id: Ie2ea668559d52d42b747260ea69a6d5b3d70e859 Reviewed-on: https://go-review.googlesource.com/29073Reviewed-by:
-
Jean-Nicolas Moal authored
For #16360. Change-Id: Iaa3548704786018eacec530f7a907b976fa532fe Reviewed-on: https://go-review.googlesource.com/27443 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Hiroshi Ioka authored
EvalSymlinks returns error if given path or its target path don't exist. Add a test for future improvement. Change-Id: Ic9a4aa5eaee0fe7ac523d54d8eb3132a11b380b3 Reviewed-on: https://go-review.googlesource.com/27330Reviewed-by:
-
Dave Cheney authored
This change adds runtime/trace support to go tool compile. Change-Id: I6c496b9b063796123f75eba6af511c53a57c0196 Reviewed-on: https://go-review.googlesource.com/25354 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
