- 13 Mar, 2019 22 commits
-
-
Matthew Dempsky authored
Based on suggestion from gri@ on golang.org/cl/166980. Passes toolstash-check. Change-Id: I79b66bb09b5635f3a9daecaa5d605b661a0ab108 Reviewed-on: https://go-review.googlesource.com/c/go/+/167501 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Change-Id: I33f5b5051e5f75aa264ec656926223c5a3c09c1b Reviewed-on: https://go-review.googlesource.com/c/go/+/167498 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matt Layher <mdlayher@gmail.com>
-
Bryan C. Mills authored
Fixes #30758 Change-Id: I8e49958602de9caa47bb5710828158e51744f375 Reviewed-on: https://go-review.googlesource.com/c/go/+/167478 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Martí authored
The len godoc uses a blockquote to list the rules for its semantics. The item that describes channels is a bit long, so it's split in two lines. However, the first line ends with a semicolon, and the second line can be read as a sentence of its own, so it's easy to misinterpret that the two lines are separate. Making that easy mistake would lead to an incorrect understanding of len: if v is nil, len(v) is zero. This could lead us to think that len(nil) is valid and should return zero. When in fact, that statement only applies to nil channels. To make this less ambiguous, add a bit of indentation to the follow-up line, to align with the channel body. If lists are added to godoc in the future via #7873, perhaps this text can be simplified. Fixes #30349. Change-Id: I84226edc812d429493137bcc65c332e92d4e6c87 Reviewed-on: https://go-review.googlesource.com/c/go/+/167403 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Somebody wasn't using goimports. :) Change-Id: Ibad3c0781ea70d538592b2e90d8b578e4fae8173 Reviewed-on: https://go-review.googlesource.com/c/go/+/167385Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Hana Kim authored
`go build` has chosen the last element of the package import path as the default output name when -o option is given. That caused the output of a package build when the module root is the major version component such as 'v2'. A similar issue involving `go install` was fixed in https://golang.org/cl/128900. This CL refactors the logic added with the change and makes it available as internal/load.DefaultExecName. This CL makes 'go test' to choose the right default test binary name when the tested package is in the module root. (E.g., instead of v2.test, choose pkg.test for the test of 'path/pkg/v2') Fixes #27283. Change-Id: I6905754f0906db46e3ce069552715f45356913ae Reviewed-on: https://go-review.googlesource.com/c/go/+/140863Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Matthew Dempsky authored
Change-Id: Ib55f2458c75aee49302f0dd4e2a819f9931a5ed3 Reviewed-on: https://go-review.googlesource.com/c/go/+/166982 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 only ways to construct an OLITERAL node are (1) a basic literal from the source package, (2) constant folding within evconst (which only folds Go language constants), (3) the universal "nil" constant, and (4) implicit conversions of nil to some concrete type. Passes toolstash-check. Change-Id: I30fc6b07ebede7adbdfa4ed562436cbb7078a2ff Reviewed-on: https://go-review.googlesource.com/c/go/+/166981 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
All setconst calls now happen within evconst. While here, get rid of callrecv, which (incompletely) duplicates the logic of hascallchan. Passes toolstash-check. Change-Id: Ic67b9dd2a1b397d4bc25e8c8b6f81daf4f6cfb75 Reviewed-on: https://go-review.googlesource.com/c/go/+/166980 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Ilya Tocar authored
We already have a pure go code sequence that is compiled into single load. Just use it everywhere, instead of pointer hackery. Passes toolstash-check. Change-Id: I0c42b5532fa9a5665da3385913609c6d42aaff27 Reviewed-on: https://go-review.googlesource.com/c/go/+/118568 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Clément Chigot authored
Change-Id: Ib98c7ad91d83ce68811f5c671200462c5fee0fca Reviewed-on: https://go-review.googlesource.com/c/go/+/167398 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
Michael Munday authored
This reduces the number of extra bounds check hints we need to insert. For example, rather than producing: _ = v.Args[2] x := v.Args[0] y := v.Args[1] z := v.Args[2] We now produce: z := v.Args[2] x := v.Args[0] y := v.Args[1] This gets rid of about 7000 lines of code from the rewrite rules. Change-Id: I1291cf0f82e8d035a6d65bce7dee6cedee04cbcd Reviewed-on: https://go-review.googlesource.com/c/go/+/167397Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Change-Id: I0223d935184017e841d56abe114d78b670457c5a Reviewed-on: https://go-review.googlesource.com/c/go/+/167437 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Carlos Eduardo Seo authored
ppc64{,le} processor level selection allows the compiler to generate instructions targeting newer processors and processor-specific optimizations without breaking compatibility with our current baseline. This feature introduces a new environment variable, GOPPC64. GOPPC64 is a GOARCH=ppc64{,le} specific option, for a choice between different processor levels (i.e. Instruction Set Architecture versions) for which the compiler will target. The default is 'power8'. Change-Id: Ic152e283ae1c47084ece4346fa002a3eabb3bb9e Reviewed-on: https://go-review.googlesource.com/c/go/+/163758 Run-TryBot: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
David Chase authored
When a jump at the end of a block is about to be marked as a statement, if the first real instruction in the target block is also a statement for the same line, remove the mark from the jump. This is a first effort at a minimal-harm heuristic. A better heuristic might skip over any "not-statement" values preceding a definitely marked value. Fixes #29443. Change-Id: Ibd52783713b4936e0c2dfda8d708bf186f33b00a Reviewed-on: https://go-review.googlesource.com/c/go/+/159977 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Bryan C. Mills authored
Fixes #30571 Change-Id: Id4c74e83ee58a080d1c2894ae5ebdbf4aeb1ce42 Reviewed-on: https://go-review.googlesource.com/c/go/+/167084 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Martí authored
This internally exported function allowed merging environment variable lists, and was mostly a convenience for the rest of cmd/go/internal. It seems to date all the way back to 2013. However, since CL 37586 in early 2017, os/exec has already taken care of deduplicating environment variable lists. Thus, it's unnecessary for cmd/go to take care of that before calling exec.Cmd.Start. Moreover, because os/exec will deduplicate the list in any case, we're adding extra work in all these scenarios. Finally, remove an unnecessary addition of GOROOT= in internal/tool. cfg.OrigEnv may not have the correct GOROOT set up, but os.Environ does; cmd/go's main function makes sure of that. Change-Id: I1f92f65fb927dc15bc7b0397cfd1a572b6337bb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/164703 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Daniel Martí authored
Most of the decoding time is spent in the first Decode loop, since the rest of the function only deals with the few remaining bytes. Any unnecessary work done in that loop body matters tremendously. One such unnecessary bottleneck was the use of the enc.decodeMap table. Since enc is a pointer receiver, and the field is used within the non-inlineable function decode64, the decoder must perform a nil check at every iteration. To fix that, move the enc.decodeMap uses to the parent function, where we can lift the nil check outside the loop. That gives roughly a 15% speed-up. The function no longer performs decoding per se, so rename it. While at it, remove the now unnecessary receivers. An unfortunate side effect of this change is that the loop now contains eight bounds checks on src instead of just one. However, not having to slice src plus the nil check removal well outweigh the added cost. The other piece that made decode64 slow was that it wasn't inlined, and had multiple branches. Use a simple bitwise-or trick suggested by Roger Peppe, and collapse the rest of the bitwise logic into a single expression. Inlinability and the reduced branching give a further 10% speed-up. Finally, add these two functions to TestIntendedInlining, since we want them to stay inlinable. Apply the same refactor to decode32 for consistency, and to let 32-bit architectures see a similar performance gain for large inputs. name old time/op new time/op delta DecodeString/2-8 47.3ns ± 1% 45.8ns ± 0% -3.28% (p=0.002 n=6+6) DecodeString/4-8 55.8ns ± 2% 51.5ns ± 0% -7.71% (p=0.004 n=5+6) DecodeString/8-8 64.9ns ± 0% 61.7ns ± 0% -4.99% (p=0.004 n=5+6) DecodeString/64-8 238ns ± 0% 198ns ± 0% -16.54% (p=0.002 n=6+6) DecodeString/8192-8 19.5µs ± 0% 14.6µs ± 0% -24.96% (p=0.004 n=6+5) name old speed new speed delta DecodeString/2-8 84.6MB/s ± 1% 87.4MB/s ± 0% +3.38% (p=0.002 n=6+6) DecodeString/4-8 143MB/s ± 2% 155MB/s ± 0% +8.41% (p=0.004 n=5+6) DecodeString/8-8 185MB/s ± 0% 195MB/s ± 0% +5.29% (p=0.004 n=5+6) DecodeString/64-8 369MB/s ± 0% 442MB/s ± 0% +19.78% (p=0.002 n=6+6) DecodeString/8192-8 560MB/s ± 0% 746MB/s ± 0% +33.27% (p=0.004 n=6+5) Updates #19636. Change-Id: Ib839577b0e3f5a2bb201f5cae580c61365d92894 Reviewed-on: https://go-review.googlesource.com/c/go/+/151177 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: roger peppe <rogpeppe@gmail.com>
-
Mikio Hara authored
This change makes it possible the runtime-integrated network poller and APIs in the package internal/poll to report an event scanning error on a read event. The latest Go releases open up the way of the manipulation of the poller for users. On the other hand, it starts misleading users into believing that the poller accepts any user-configured file or socket perfectly because of not reporting any error on event scanning, as mentioned in issue 30426. The initial implementation of the poller was designed for just well-configured, validated sockets produced by the package net. However, the assumption is now obsolete. Fixes #30624. Benchmark results on linux/amd64: benchmark old ns/op new ns/op delta BenchmarkTCP4OneShot-4 24649 23979 -2.72% BenchmarkTCP4OneShotTimeout-4 25742 24411 -5.17% BenchmarkTCP4Persistent-4 5139 5222 +1.62% BenchmarkTCP4PersistentTimeout-4 4919 4892 -0.55% BenchmarkTCP6OneShot-4 21182 20767 -1.96% BenchmarkTCP6OneShotTimeout-4 23364 22305 -4.53% BenchmarkTCP6Persistent-4 4351 4366 +0.34% BenchmarkTCP6PersistentTimeout-4 4227 4255 +0.66% BenchmarkTCP4ConcurrentReadWrite-4 2309 1839 -20.36% BenchmarkTCP6ConcurrentReadWrite-4 2180 1791 -17.84% benchmark old allocs new allocs delta BenchmarkTCP4OneShot-4 26 26 +0.00% BenchmarkTCP4OneShotTimeout-4 26 26 +0.00% BenchmarkTCP4Persistent-4 0 0 +0.00% BenchmarkTCP4PersistentTimeout-4 0 0 +0.00% BenchmarkTCP6OneShot-4 26 26 +0.00% BenchmarkTCP6OneShotTimeout-4 26 26 +0.00% BenchmarkTCP6Persistent-4 0 0 +0.00% BenchmarkTCP6PersistentTimeout-4 0 0 +0.00% BenchmarkTCP4ConcurrentReadWrite-4 0 0 +0.00% BenchmarkTCP6ConcurrentReadWrite-4 0 0 +0.00% benchmark old bytes new bytes delta BenchmarkTCP4OneShot-4 2000 2000 +0.00% BenchmarkTCP4OneShotTimeout-4 2000 2000 +0.00% BenchmarkTCP4Persistent-4 0 0 +0.00% BenchmarkTCP4PersistentTimeout-4 0 0 +0.00% BenchmarkTCP6OneShot-4 2144 2144 +0.00% BenchmarkTCP6OneShotTimeout-4 2144 2145 +0.05% BenchmarkTCP6Persistent-4 0 0 +0.00% BenchmarkTCP6PersistentTimeout-4 0 0 +0.00% BenchmarkTCP4ConcurrentReadWrite-4 0 0 +0.00% BenchmarkTCP6ConcurrentReadWrite-4 0 0 +0.00% Change-Id: Iab60e504dff5639e688dc5420d852f336508c0af Reviewed-on: https://go-review.googlesource.com/c/go/+/166497 Run-TryBot: Mikio Hara <mikioh.public.networking@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Clément Chigot authored
-mcmodel=large and -Wl,-bbigtoc must always be passed to gcc in order to prevent TOC overflow error. However, a warning is still issued by ld. It is removed as it doesn't give any useful information. Change-Id: I95a78e8993cc7b5c0f329654d507409785f7eea6 Reviewed-on: https://go-review.googlesource.com/c/go/+/164008 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Agniva De Sarker authored
Fixes #25492 Change-Id: Ic1496857524dad0c0a77f3bb80fa084c9bf00aa9 Reviewed-on: https://go-review.googlesource.com/c/go/+/155777 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Clément Chigot authored
DWARF relocations isn't working with some older ld, because of -Wl,-bnoobjreorder which is needed on Go. This commit checks ld's version and disable DWARF generation in cmd/link if it's too old. Some tests must therefore be skipped. Change-Id: I2e794c263eb0dfe0b42e7062fb80c26f086b44d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/164007 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 12 Mar, 2019 18 commits
-
-
Robert Griesemer authored
Fixes #30722. Change-Id: Ia4c6e37282edc44788cd8af3f6cfa10895a19e4f Reviewed-on: https://go-review.googlesource.com/c/go/+/166519Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
With math/big supporting underscores directly, there is no need to manually remove them before calling the math/big conversion routines. Updates #28493. Change-Id: I6f865c8f87c3469ffd6c33f960ed540135055226 Reviewed-on: https://go-review.googlesource.com/c/go/+/166417Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
The primary change is in nat.scan which now accepts underscores for base 0. While at it, streamlined error handling in that function as well. Also, improved the corresponding test significantly by checking the expected result values also in case of scan errors. The second major change is in scanExponent which now accepts underscores when the new sepOk argument is set. While at it, essentially rewrote that function to match error and underscore handling of nat.scan more closely. Added a new test for scanExponent which until now was only tested indirectly. Finally, updated the documentation for several functions and added many new test cases to clients of nat.scan. A major portion of this CL is due to much better test coverage. Updates #28493. Change-Id: I7f17b361b633fbe6c798619d891bd5e0a045b5c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/166157Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
Daniel Martí authored
Lines with single cells prompt a flush. Unfortunately, a call to Writer.Flush also means two defers, which is an expensive operation to do if many lines consist of single cells. This is common when formatting code with aligned comments. Most lines aren't going to have any comments at all, so the performance hit is going to be noticeable. The Write method already has a "defer handlePanic" of its own, so we don't need to worry about panics leaking out. The error will now mention "Write" instead of "Flush" if a panic is encountered during that nested flush, but arguably that's a good thing; the user called Write, not Flush. For the reset call, add a non-deferred call as part of flushNoDefers, as that's still necessary. Otherwise, the exported Flush method still does a "defer b.reset". The current tabwriter benchmarks are unaffected, since they don't contain many single-cell lines, and because lines are written one at a time. For that reason, we add a benchmark which has both of these characteristics. name old time/op new time/op delta Code-8 2.72µs ± 0% 1.77µs ± 0% -34.88% (p=0.000 n=6+5) name old alloc/op new alloc/op delta Code-8 648B ± 0% 648B ± 0% ~ (all equal) name old allocs/op new allocs/op delta Code-8 13.0 ± 0% 13.0 ± 0% ~ (all equal) Perhaps unsurprisingly, go/printer also gets a bit faster, as it too buffers its output before writing it to tabwriter. name old time/op new time/op delta Print-8 6.53ms ± 0% 6.39ms ± 0% -2.22% (p=0.008 n=5+5) Change-Id: Ie01fea5ced43886a9eb796cb1e6c810f7a810853 Reviewed-on: https://go-review.googlesource.com/c/go/+/166797 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Bryan C. Mills authored
I typo'd this variable in CL 165745, and neither I, the reviewer, nor the TryBots noticed. But the longtest builder noticed, and it's not happy about it. Updates #30571 Change-Id: I5e3d267346407855ec0d1f340a72dc2c521ecc63 Reviewed-on: https://go-review.googlesource.com/c/go/+/167086 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
This test invokes 'go build', so in module mode it needs a module cache to guard edits to go.mod. Fixes #30776 Change-Id: I89ebef1fad718247e7f972cd830e31d6f4a83e4c Reviewed-on: https://go-review.googlesource.com/c/go/+/167085 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
The sheer length of the generated rules files makes my editor and git client unhappy. This change is a small step towards shortening them. We recognize a few magic variables during rulegen: b, config, fe, typ. Of these, only b appears prone to false positives. By tightening the heuristic and fixing one case in MIPS.rules, we can make the heuristic enough that it has no failures. That allows us to remove the hedge assignments to _, removing 3000 pointless lines of code. Change-Id: I080cde5db28c8277cb3fd9ddcd829306c9a27785 Reviewed-on: https://go-review.googlesource.com/c/go/+/166979 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Bryan C. Mills authored
Fixes #30756 Change-Id: I046d43df56faac8fc09d53dc1e87a014dd6d530b Reviewed-on: https://go-review.googlesource.com/c/go/+/167080 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
Change-Id: Ib268157674824fd7552d3c36a61eccf8c720eaeb Reviewed-on: https://go-review.googlesource.com/c/go/+/167083 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Shubham Sharma authored
Fixes #30123 Change-Id: I310b89a344a262bb758d39dfdd485ed2940cc6aa Reviewed-on: https://go-review.googlesource.com/c/go/+/166577 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Bryan C. Mills authored
GOPATH/pkg contains, among other things, the module cache (and associated lockfiles). Fixes #30776 Change-Id: I305cb3c0daab8cedd2e6ad235d4733f66af18723 Reviewed-on: https://go-review.googlesource.com/c/go/+/167082Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
Chdir leaves the test in the wrong working directory if objdumpOutput calls t.Fatalf (or panics), and it isn't necessary here anyway. Set the Dir field on the commands instead. Change-Id: I9f0eb0d4f8d15043f1e13472126ca1a1ce4b7cb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/167081 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Robert Griesemer authored
This CL documents the new binary and octal integer literals, hexadecimal floats, generalized imaginary literals and digit separators for all number literals in the spec. Added empty lines between abutting paragraphs in some places (a more thorough cleanup can be done in a separate CL). A minor detail: A single 0 was considered an octal zero per the syntax (decimal integer literals always started with a non-zero digit). The new octal literal syntax allows 0o and 0O prefixes and when keeping the respective octal_lit syntax symmetric with all the others (binary_lit, hex_lit), a single 0 is not automatically part of it anymore. Rather than complicating the new octal_lit syntax to include 0 as before, it is simpler (and more natural) to accept a single 0 as part of a decimal_lit. This is purely a notational change. R=Go1.13 Updates #12711. Updates #19308. Updates #28493. Updates #29008. Change-Id: Ib9fdc6e781f6031cceeed37aaed9d05c7141adec Reviewed-on: https://go-review.googlesource.com/c/go/+/161098Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ben Hoyt authored
This change adds a fast path for ASCII strings to both strings.TrimSpace and bytes.TrimSpace. It doesn't slow down the non-ASCII path much, if at all. I added benchmarks for strings.TrimSpace as it didn't have any, and I fleshed out the benchmarks for bytes.TrimSpace as it just had one case (for ASCII). The benchmarks (and the code!) are now the same between the two versions. Below are the benchmark results: strings.TrimSpace: name old time/op new time/op delta TrimSpace/NoTrim-8 18.6ns ± 0% 3.8ns ± 0% -79.53% (p=0.000 n=5+4) TrimSpace/ASCII-8 33.5ns ± 2% 6.0ns ± 3% -82.05% (p=0.008 n=5+5) TrimSpace/SomeNonASCII-8 97.1ns ± 1% 88.6ns ± 1% -8.68% (p=0.008 n=5+5) TrimSpace/JustNonASCII-8 144ns ± 0% 143ns ± 0% ~ (p=0.079 n=4+5) bytes.TrimSpace: name old time/op new time/op delta TrimSpace/NoTrim-8 18.9ns ± 1% 4.1ns ± 1% -78.34% (p=0.008 n=5+5) TrimSpace/ASCII-8 29.9ns ± 0% 6.3ns ± 1% -79.06% (p=0.008 n=5+5) TrimSpace/SomeNonASCII-8 91.5ns ± 0% 82.3ns ± 0% -10.03% (p=0.008 n=5+5) TrimSpace/JustNonASCII-8 150ns ± 0% 150ns ± 0% ~ (all equal) Fixes #29122 Change-Id: Ica45cd86a219cadf60173ec9db260133cd1d7951 Reviewed-on: https://go-review.googlesource.com/c/go/+/152917Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Elias Naur authored
strings.HasPrefix is not good enough to determine whether a path is a subdirectory of another because it does not respect path boundaries. filepath.Rel is good eonugh as long as we filter out results that use parent directories, "..". Hopefully fix the android emulator builders on the subrepositories. Change-Id: I17ee7e0028c0b0b26a6c5f67629f53c9a660c6e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/167117 Run-TryBot: Elias Naur <mail@eliasnaur.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
This fixes the root cause of the bootstrap failure reported in https://groups.google.com/d/msg/golang-dev/xcVJDj5GJ84/U0pVnUOnBwAJ. Updates #30228 Change-Id: I9ce0898922a5aac1f61ceff30319cf88031676c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/167079 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
Updates #30228 Change-Id: Ica28525b31a8a787875c147e16274eba8f4dbffc Reviewed-on: https://go-review.googlesource.com/c/go/+/167078 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
I thought I had removed all of the 'mod=vendor' hacks I had inserted previously, but apparently missed this one in a bad merge or rebase. Updates #30228 Change-Id: Ia5aea754bf986458373fefd08fa9dd3941e31e43 Reviewed-on: https://go-review.googlesource.com/c/go/+/167077 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-