- 14 Aug, 2017 1 commit
-
-
Josh Bleecher Snyder authored
This reduces the wall time to run these benchmarks by about 30%. Change-Id: I494a93c93e5acb1514510d85f65796f62e1629a5 Reviewed-on: https://go-review.googlesource.com/54650 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
-
- 13 Aug, 2017 6 commits
-
-
Austin Clements authored
Currently we only support finding symbols in the VDSO using the old DT_HASH. These days everything uses DT_GNU_HASH instead. To keep up with the times and future-proof against DT_HASH disappearing from the VDSO in the future, this commit adds support for DT_GNU_HASH and prefers it over DT_HASH. Tested by making sure it found a DT_GNU_HASH section and all of the expected symbols in it, and then disabling the DT_GNU_HASH path and making sure the old DT_HASH path still found all of the symbols. Fixes #19649. Change-Id: I508c8b35a019330d2c32f04f3833b69cb2686f13 Reviewed-on: https://go-review.googlesource.com/45511 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Audrey Lim authored
The ZIP format uses uint16 to contain the length of the file name and the length of the Extra section. This change verifies that the length of these fields fit in an uint16 prior to writing the ZIP file. If not, an error is returned. Fixes #17402 Change-Id: Ief9a864d2fe16b89ddb9917838283b801a2c58a4 Reviewed-on: https://go-review.googlesource.com/50250Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
If needed cast the test table values to a higher bit size integer type instead of casting the result values of the tested function to a lower bit size integer type. Change-Id: Iaa79742b2b1d90c7c7eac324f54032ebea0b1b41 Reviewed-on: https://go-review.googlesource.com/55137Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Martin Möhrmann authored
Increases performance of FieldsFunc by recording the start and end of the fields in an array. The first 32 fields are saved in a pre-allocated array on the stack. This avoids the old behavior of iterating over the input string two times but uses more allocations when more than 32 fields are encountered. Additionally code for handling non-ASCII containing strings from Fields is removed and replaced by a call to the new faster FieldsFunc function. Overall this still leads to a slowdown for Fields on non-ASCII strings while speeding up Fields in general. name old time/op new time/op delta Fields/ASCII/16 116ns ± 5% 115ns ± 5% ~ (p=0.480 n=10+10) Fields/ASCII/256 765ns ± 1% 761ns ± 2% ~ (p=0.171 n=10+10) Fields/ASCII/4096 12.5µs ± 1% 12.7µs ± 1% +1.82% (p=0.000 n=10+10) Fields/ASCII/65536 226µs ± 1% 226µs ± 2% ~ (p=0.739 n=10+10) Fields/ASCII/1048576 5.12ms ± 1% 5.12ms ± 1% ~ (p=0.696 n=8+10) Fields/Mixed/16 172ns ± 1% 233ns ± 1% +35.90% (p=0.000 n=9+10) Fields/Mixed/256 1.18µs ± 2% 2.45µs ± 1% +107.47% (p=0.000 n=10+10) Fields/Mixed/4096 20.3µs ± 1% 43.1µs ± 2% +112.41% (p=0.000 n=10+10) Fields/Mixed/65536 364µs ± 1% 704µs ± 1% +93.56% (p=0.000 n=9+10) Fields/Mixed/1048576 7.07ms ± 2% 13.34ms ± 4% +88.83% (p=0.000 n=10+10) FieldsFunc/ASCII/16 274ns ± 1% 188ns ± 3% -31.44% (p=0.000 n=10+10) FieldsFunc/ASCII/256 3.69µs ± 1% 2.06µs ± 2% -44.26% (p=0.000 n=10+10) FieldsFunc/ASCII/4096 59.9µs ± 1% 35.3µs ± 2% -41.10% (p=0.000 n=10+10) FieldsFunc/ASCII/65536 958µs ± 1% 567µs ± 1% -40.82% (p=0.000 n=10+9) FieldsFunc/ASCII/1048576 16.3ms ± 2% 11.0ms ± 3% -32.52% (p=0.000 n=10+10) FieldsFunc/Mixed/16 309ns ± 1% 213ns ± 0% -30.98% (p=0.000 n=10+6) FieldsFunc/Mixed/256 3.83µs ± 1% 2.14µs ± 1% -44.01% (p=0.000 n=10+10) FieldsFunc/Mixed/4096 66.2µs ± 2% 37.8µs ± 1% -42.85% (p=0.000 n=10+10) FieldsFunc/Mixed/65536 1.09ms ± 1% 0.63ms ± 1% -42.73% (p=0.000 n=10+10) FieldsFunc/Mixed/1048576 18.6ms ± 3% 12.0ms ± 2% -35.50% (p=0.000 n=10+10) Fixes #17856 Fixes #19789 Change-Id: I9f5a560e534566fd81963651f342c8f44cfb0469 Reviewed-on: https://go-review.googlesource.com/42810Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Martin Möhrmann authored
If the value corresponding to the input string cannot be represented by an unsigned integer of the given size, err.Err = ErrRange and the returned value is the maximum magnitude unsigned integer of the appropriate bitSize. This is consistent with ParseInt's behavior and the documentation. Expand tests to test 32 bit test value tables with bitsize 32 set. These tests fail without the fix in this CL. Fixes #21278 Change-Id: I8aab39279ec3e31905fcbf582a916cbf6d9b95da Reviewed-on: https://go-review.googlesource.com/55134 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Joe Tsai authored
Use a simple []byte instead of bytes.Buffer to create a string. Use bytes.IndexByte instead of our own for loop. Change-Id: Ic4a1161d79017fd3af086a05c53d5f20a5f09326 Reviewed-on: https://go-review.googlesource.com/54752Reviewed-by: Avelino <t@avelino.xxx> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
-
- 12 Aug, 2017 4 commits
-
-
Agniva De Sarker authored
By replacing fmt.Sprintf with a simple string concat, we see pretty good improvements across the board on time and memory. name old time/op new time/op delta FormatPAXRecord 683ns ± 2% 210ns ± 5% -69.22% (p=0.000 n=10+10) name old alloc/op new alloc/op delta FormatPAXRecord 112B ± 0% 32B ± 0% -71.43% (p=0.000 n=10+10) name old allocs/op new allocs/op delta FormatPAXRecord 8.00 ± 0% 2.00 ± 0% -75.00% (p=0.000 n=10+10) Ran with - -cpu=1 -count=10 on an AMD64 i5-5200U CPU @ 2.20GHz Using the following benchmark: func BenchmarkFormatPAXRecord(b *testing.B) { for n := 0; n < b.N; n++ { formatPAXRecord("foo", "bar") } } Change-Id: I828ddbafad2e5d937f0cf5f777b512638344acfc Reviewed-on: https://go-review.googlesource.com/55210Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Joe Tsai authored
Rather than going through the complicated logic of writeHeader, implement a writeUSTARHeader that only knows about the USTAR format. This makes the logic much easier to reason about since you only need to be concerned about USTAR and not all the subtle differences between USTAR, PAX, and GNU. We seperate out the logic in writeUSTARHeader into templateV7Plus and writeRawHeader since the planned implementations of writePAXHeader and writeGNUHeader will use them. Change-Id: Ie75a54ac998420ece82686159ae6fa39f8b128e9 Reviewed-on: https://go-review.googlesource.com/54970Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mark Wolfe authored
Change-Id: I27ff99aa7abb070f6ae79c8f964aa9bd6a83b89d Reviewed-on: https://go-review.googlesource.com/53730Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel Odeke authored
Ensure that we can index maps whose key types are: * int * uint * int32 * uint32 * int64 * uint64 * uintptr Fixes #20439 Change-Id: I8fa96b14073c8af72786482ff4ffc3508064ea86 Reviewed-on: https://go-review.googlesource.com/43850 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 11 Aug, 2017 29 commits
-
-
Elias Naur authored
The dieFromSignal runtime function attempts to forward crashing signals to a signal handler registered before the runtime was initialized, if any. However, on Darwin, a special signal handler trampoline is invoked, even for non-Go signal handlers. Clear the crashing signal's handlingSig entry to ensure sigtramp forwards the signal. Fixes the darwin/386 builder. Updates #20392 Updates #19389 Change-Id: I441a3d30c672cdb21ed6d8f1e1322d7c0e5b9669 Reviewed-on: https://go-review.googlesource.com/55032 Run-TryBot: Elias Naur <elias.naur@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hiroshi Ioka authored
According to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_key_create.html, pthread_key_create return an error number which is greater than or equal to 0. I don't know the scenario that pthread_setspecific would fail, but also don't know the future. Add some error handlings just in case. Change-Id: I0774b79ef658d67e300f4a9aab1f2e3879acc7ee Reviewed-on: https://go-review.googlesource.com/54811Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cholerae Hu authored
Intrinsic enabled on all architectures, runtime asm implementation removed on all architectures. Fixes #21258 Change-Id: I2cb86d460b497c2f287a5b3df5c37fdb231c23a7 Reviewed-on: https://go-review.googlesource.com/53411Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: David Chase <drchase@google.com>
-
Alberto Donizetti authored
$ go tool -h says: For more about each tool command, see 'go tool command -h'. but it was suggested to change the suggestion to say: see 'go doc command' In #18313. That would work for every tool except dist, which has no doc.go. This change adds a doc.go file to cmd/dist. Updates #18313 Change-Id: If67a21934b87647a69359d9c14d8de3775c587b7 Reviewed-on: https://go-review.googlesource.com/54351 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Currently all trace slices get shifted to start at time 0. This makes it very difficult to find specific points in time unless they fall in the first slice. For example, right now when you click "View trace (6.005646218s-8.155419698s)" on the trace tool's main page, the trace view puts the first event in that slice at time 0. If you're looking for something that happened at time 7s, you have to look at time 0.9943537s in the trace view. And if you want to subtract times taken from different slices, you have to figure out what those time really correspond to. Fix this by telling the trace viewer not to shift the times when it imports the trace. In the above example, this makes the view of that second trace slice start at time 6.005646218s, so you don't have to do any gymnastics to find or calculate times in later slices. Change-Id: I04e0afda60f5573fdd8ad96238c24013297ef263 Reviewed-on: https://go-review.googlesource.com/54633Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This updates the HTML served for the trace viewer to follow the latest revision of the example from the upstream tracing project. The main thing this adds is CSS for the trace viewer (which was actually in the example at the originally referenced revision, so I'm not sure why it got dropped). In particular, this expands the trace viewer to use the entire browser client area, which fixes several problems with the current page: 1. The details pane gets cut off at a strange place and can get a scroll bar even if there's plenty of room below it on the page. This fixes the bottom of the details pane to the bottom of the window. 2. If the track view is very tall (lots of procs), there's no way to view the top tracks and the details pane at the same time. This fixes this problem by limiting the height of the track view to something less than the height of the window so it gets a scroll bar of its own if necessary. 3. Dragging the divider between the track pane and the details pane actually moves the bottom of the details pane without moving the divider. Fixing the height of the trace viewer fixes this problem. Change-Id: Ia811e72a7413417ca21c45e932c9db2724974633 Reviewed-on: https://go-review.googlesource.com/54632 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Gerrit Code Review authored
-
Carlos Eduardo Seo authored
_main has an early check to verify if a binary is statically or dynamically linked that depends on R0 being zero. R0 is not guaranteed to be zero at that point and this was breaking Go on Alpine for ppc64le. Change-Id: I4a1059ff7fd3db6fc489e7dcfe631c1814dd965b Reviewed-on: https://go-review.googlesource.com/54730 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
-
Tobias Klauser authored
The gofmt bug in question seems to be fixed (at least gofmt doesn't complain), so reenable the commented-out ... test. Change-Id: Icbfe0511160210557894ec8eb9b206aa6133d486 Reviewed-on: https://go-review.googlesource.com/55030 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
This implements trunc, floor, and ceil in the math package as intrinsics on ppc64x. Significant improvement mainly due to avoiding call overhead of args and return value. BenchmarkCeil-16 5.95 0.69 -88.40% BenchmarkFloor-16 5.95 0.69 -88.40% BenchmarkTrunc-16 5.82 0.69 -88.14% Updates #21390 Change-Id: I951e182694f6e0c431da79c577272b81fb0ebad0 Reviewed-on: https://go-review.googlesource.com/54654 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: David Chase <drchase@google.com>
-
Austin Clements authored
Change-Id: I85df2745af666b533f4f6f1d06f7c8e137590b5b
-
Carlos Eduardo Seo authored
This change adds a better implementation in asm for AddMulVVW and mulAddVWW for ppc64x, with speedups up to 1.54x. benchmark old ns/op new ns/op delta BenchmarkAddMulVVW/1-8 6.58 6.29 -4.41% BenchmarkAddMulVVW/2-8 7.43 7.25 -2.42% BenchmarkAddMulVVW/3-8 8.95 8.15 -8.94% BenchmarkAddMulVVW/4-8 10.1 9.37 -7.23% BenchmarkAddMulVVW/5-8 12.0 10.7 -10.83% BenchmarkAddMulVVW/10-8 22.1 20.1 -9.05% BenchmarkAddMulVVW/100-8 211 154 -27.01% BenchmarkAddMulVVW/1000-8 2046 1450 -29.13% BenchmarkAddMulVVW/10000-8 20407 14793 -27.51% BenchmarkAddMulVVW/100000-8 223857 145548 -34.98% benchmark old MB/s new MB/s speedup BenchmarkAddMulVVW/1-8 9719.88 10175.79 1.05x BenchmarkAddMulVVW/2-8 17233.97 17657.54 1.02x BenchmarkAddMulVVW/3-8 21446.05 23550.49 1.10x BenchmarkAddMulVVW/4-8 25375.70 27334.33 1.08x BenchmarkAddMulVVW/5-8 26650.52 30029.34 1.13x BenchmarkAddMulVVW/10-8 28984.29 31833.68 1.10x BenchmarkAddMulVVW/100-8 30249.41 41531.69 1.37x BenchmarkAddMulVVW/1000-8 31273.35 44108.54 1.41x BenchmarkAddMulVVW/10000-8 31360.47 43263.54 1.38x BenchmarkAddMulVVW/100000-8 28589.58 43971.66 1.54x Change-Id: I8a8105d4da3592afdef3125757a99f378a0254bb Reviewed-on: https://go-review.googlesource.com/53931 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
-
romanyx authored
Change-Id: Icdd0566d3b7dbc034256e16f8a6b6f1af07069b3 Reviewed-on: https://go-review.googlesource.com/54350Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brian Kessler authored
As noted in the TODO comment, the sticky bit is only used when the rounding bit is zero or the rounding mode is ToNearestEven. This change makes that check explicit and will eliminate half the sticky bit calculations on average when rounding mode is not ToNearestEven. Change-Id: Ia4709f08f46e682bf97dabe5eb2a10e8e3d7af43 Reviewed-on: https://go-review.googlesource.com/54111Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Hiroshi Ioka authored
Although mincore is declared in stubs.go, mincore isn't used by any OSes except linux. Move it to os_linux.go and clean up unused code. Change-Id: I6cfb0fed85c0317a4d091a2722ac55fa79fc7c9a Reviewed-on: https://go-review.googlesource.com/54910Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Martí authored
This parameter is always false. The last occurrence of s.skipSpace(true) was removed in mid-2015. While at it, merge skipSpace into SkipSpace, since the latter was just a wrapper without the parameter. Found with github.com/mvdan/unparam. Change-Id: I884ea4036f41234a898d6aeee515211c49b0b435 Reviewed-on: https://go-review.googlesource.com/52890Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Avelino <t@avelino.xxx> Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
-
Hiroshi Ioka authored
Change-Id: Ib5356181c3204c8f9922eeb4da1c06bfdb18f443 Reviewed-on: https://go-review.googlesource.com/54812Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hiroshi Ioka authored
Change-Id: I8d295ea32bf56adc42171947133f3e16a88664c6 Reviewed-on: https://go-review.googlesource.com/54911Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Joe Tsai authored
The current logic in writeHeader attempts to encode the Header in one format and if it discovered that it could not it would attempt to switch to a different format mid-way through. This makes it very hard to reason about what format will be used in the end and whether it will even be a valid format. Instead, we should verify from the start what formats are allowed to encode the given input Header. If no formats are possible, then we can return immediately, rejecting the Header. For now, we continue on to the hairy logic in writeHeader, but a future CL can split that logic up and specialize them for each format now that we know what is possible. Update #9683 Update #12594 Change-Id: I8406ea855dfcb8b478a03a7058ddf8b2b09d46dc Reviewed-on: https://go-review.googlesource.com/54433 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Alex Brainman authored
I also wanted to test net sockets, but I do not know how to access their file handles. So I did not implement socket tests. Updates #21172 Change-Id: I5062c0e65a817571d755397d60762c175f9791ce Reviewed-on: https://go-review.googlesource.com/53530Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
The prior logic would over-write the NUL-terminator if the octal value was long enough. In order to prevent this, we add a fitsInOctal function that does the proper check. The relevant USTAR specification about NUL-terminator is: <<< Each numeric field is terminated by one or more <space> or NUL characters. >>> Change-Id: I6fbc6e8fe71168727eea201925d0fe08d43116ac Reviewed-on: https://go-review.googlesource.com/54432Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
USTAR and GNU strings are NUL-terminated. Thus, we should never allow the NUL terminator, otherwise we will lose data round-trip. Relevant specification text: <<< The fields magic, uname, and gname are character strings each terminated by a NUL character. > > Technically, PAX keys and values should be UTF-8, but the observance > of invalid files in the wild causes us to be more liberal. > <<< > The <length> field, <blank>, <equals-sign>, and <newline> shown shall > be limited to the portable character set, as encoded in UTF-8. Thus, we only reject NULs in PAX keys, and NULs for PAX values representing the USTAR string fields (i.e., path, linkpath, uname, gname). These are treated more strictly because they represent strings that are typically represented as C-strings on POSIX systems. Change-Id: I305b794d9d966faad852ff660bd0b3b0964e52bf Reviewed-on: https://go-review.googlesource.com/14724 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
Given that sparse file logic is not trivial, there should be a test in TestPartialRead to ensure that partial reads work. Change-Id: I913da3e331da06dca6758a8be3f5099abba233a6 Reviewed-on: https://go-review.googlesource.com/54430 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
The encoding/hex package provides a nice Dump formatter that prints both hex and ASCII. Use that instead for better visual debugging of binary diffs. Change-Id: Iad1084e8e52d7d523595e97ae20912657cea2ab5 Reviewed-on: https://go-review.googlesource.com/14729 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
Prior to Go1.8, the Writer had a bug where it would output an invalid tar file in certain rare situations because the logic incorrectly believed that the old GNU format had a prefix field. This is wrong and leads to an output file that mangles the atime and ctime fields, which are often left unused. In order to continue reading tar files created by former, buggy versions of Go, we skeptically parse the atime and ctime fields. If we are unable to parse them and the prefix field looks like an ASCII string, then we fallback on the pre-Go1.8 behavior of treating these fields as the USTAR prefix field. Note that this will not use the fallback logic for all possible files generated by a pre-Go1.8 toolchain. If the generated file happened to have a prefix field that parses as valid atime and ctime fields (e.g., when they are valid octal strings), then it is impossible to distinguish between an valid GNU file and an invalid pre-Go1.8 file. Fixes #21005 Change-Id: Iebf5c67c08e0e46da6ee41a2e8b339f84030dd90 Reviewed-on: https://go-review.googlesource.com/53635 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
In Go1.0, Writer.Flush used to finish off the current file with zeros (if it was not already finished) and then write the padding. Since Go1.1, a regression was made (https://golang.org/cl/5777064) where it was an error to call Flush if the current file was incomplete. Thus, Flush now only writes out the final padding bytes, which arguably isn't very useful to anyone. Since this has been the behavior of Flush for 9 releases of Go (1.1 to 1.9), we should keep this behavior and just simplify the logic. We also mark the method as deprecated since it serves no purpose. Change-Id: I94610d942cb75cad495efd8cf799c1a275a21751 Reviewed-on: https://go-review.googlesource.com/54434 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hiroshi Ioka authored
Change-Id: I84b0e1d86728a76bc6a87fee4accf6fc43d87006 Reviewed-on: https://go-review.googlesource.com/54814Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
molivier authored
Change-Id: I78f4ec32c6445015ce626a552edcba561eb650fa Reviewed-on: https://go-review.googlesource.com/54710Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
-
Tobias Klauser authored
https://golang.org/cl/37508 added an escape analysis test for #12397 to escape2.go but missed to add it to escape2n.go. The comment at the top of the former states that the latter should contain all the same tests and the tests only differ in using -N to compile. Conform to this by adding the function issue12397 to escape2n.go as well. Also fix a whitespace difference in escape2.go, so the two files match exactly (except for the comment at the top). Change-Id: I3a09cf95169bf2150a25d6b4ec9e147265d36760 Reviewed-on: https://go-review.googlesource.com/54610Reviewed-by: Avelino <t@avelino.xxx> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
-