This is a regression introduced in golang.org/cl/28817. That change got
rid of the iota, which meant that the type was no longer applied to all
the constant names.
Re-add the iota starting at -1, simplifying the code and adding the
types once more.
Change-Id: I38bd0e04f8d298196bccd33651e29f5011401a8d
Reviewed-on: https://go-review.googlesource.com/78617
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 65851 (bytes) and CL 65910 (strings) “improve[d] readability”
by removing the special case that bypassed the whole function body
when chars == "". In doing so, yes, the function was unindented a
level, which is nice, but the runtime of that case went from O(1) to O(n)
where n = len(s).
I don't know if anyone's code depends on the O(1) behavior in this case,
but quite possibly someone's does.
This CL adds the special case back, with a comment to prevent future
deletions, and without reindenting each function body in full.
Change-Id: I5aba33922b304dd1b8657e6d51d6c937a7f95c81
Reviewed-on: https://go-review.googlesource.com/78112
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This should help make clear that Len is not counting runes.
Also delete empty string, which doesn't add much.
Change-Id: I1602352df1897fef6e855e9db0bababb8ab788ca
Reviewed-on: https://go-review.googlesource.com/78110
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
This test was taking too long on ppc64x.
There were a few reasons.
The first is that the page size on ppc64x is 64k instead of 4k.
That's 16x more work.
The second is that the generic Index is pretty bad in this case.
It first calls IndexByte which does a bunch of setup work only to find
the byte we're looking for at index 0. Then it calls Equal which
has to look at the whole string to find a difference on the last byte.
To fix, just limit our attention to near the end of the page.
Change-Id: I6b8bcbb94652a2da853862acc23803def0c49303
Reviewed-on: https://go-review.googlesource.com/76050
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This avoids the problem in which appending to a slice returned by
Split can affect subsequent slices.
Fixes#21149.
Change-Id: Ie3df2b9ceeb9605d4625f47d49073c5f348cf0a1
Reviewed-on: https://go-review.googlesource.com/74510
Reviewed-by: Jelte Fennema <github-tech@jeltef.nl>
Reviewed-by: Robert Griesemer <gri@golang.org>
Make sure Index and IndexByte don't read past the queried byte slice.
Hopefully will be helpful for CL 33597.
Also remove the code which maps/unmaps the Go heap.
Much safer to play with protection bits off-heap.
Change-Id: I50d73e879b2d83285e1bc7c3e810efe4c245fe75
Reviewed-on: https://go-review.googlesource.com/75890
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is only to aid in human debugging, and for that reason we maintain a panic, and not return an error.
Fixes#22097
Change-Id: If72e4d1e47ec9125ca7bc97d5fe4cedb7f76ae72
Reviewed-on: https://go-review.googlesource.com/67970
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix incorrect reference to string instead of byte slice.
Change-Id: I95553da32acfbcf5dde9613b07ea38408cb31ae8
Reviewed-on: https://go-review.googlesource.com/68090
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change removes the check of len(chars) > 0 inside the Index and
IndexAny functions which was redundant.
Change-Id: Ic4bf8b8a37d7f040d3ebd81b4fc45fcb386b639a
Reviewed-on: https://go-review.googlesource.com/65851
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In golang.org/cl/42813, a test was added in the bytes package to check
if a Buffer method was being inlined, using 'go tool nm'.
Now that we have a compiler test that verifies that certain funcs are
inlineable, merge it there. Knowing whether the funcs are inlineable is
also more reliable than whether or not their symbol appears in the
binary, too. For example, under some circumstances, inlineable funcs
can't be inlined, such as if closures are used.
While at it, add a few more bytes.Buffer methods that are currently
inlined and should clearly stay that way.
Updates #21851.
Change-Id: I62066e32ef5542d37908bd64f90bda51276da4de
Reviewed-on: https://go-review.googlesource.com/65658
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Some methods that were used to implement various `io` interfaces in the
Reader were documented, whereas others were not. This change adds
documentation to all the missing methods used to implement these
interfaces.
Change-Id: I2dac6e328542de3cd87e89510651cd6ba74a7b7d
Reviewed-on: https://go-review.googlesource.com/65231
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL improves the readability of the tests in the bytes package by
naming the `data` test variable `testString`, using the same convention
as its counterpart, `testBytes`.
It additionally removes some type casting which was unnecessary.
Change-Id: If38b5606ce8bda0306bae24498f21cb8dbbb6377
Reviewed-on: https://go-review.googlesource.com/64931
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: If7ecdc57f190f647bfc673bde8e66b4ef12aa906
Reviewed-on: https://go-review.googlesource.com/64190
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Clean-up changes in no particular order:
- use uint8 instead of int for readOp
- remove duplicated code in ReadFrom()
- introduce (*Buffer).empty()
- remove naked returns
Change-Id: Ie6e673c20c398f980f8be0448969a36ad4778804
Reviewed-on: https://go-review.googlesource.com/42816
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Found with mvdan.cc/unindent. Prioritized the ones with the biggest wins
for now.
Change-Id: I2b032e45cdd559fc9ed5b1ee4c4de42c4c92e07b
Reviewed-on: https://go-review.googlesource.com/56470
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Implements detection of x86 cpu features that
are used in the go standard library.
Changes all standard library packages to use the new cpu package
instead of using runtime internal variables to check x86 cpu features.
Updates: #15403
Change-Id: I2999a10cb4d9ec4863ffbed72f4e021a1dbc4bb9
Reviewed-on: https://go-review.googlesource.com/41476
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The test "TestTryGrowByResliceInlined" introduced in c08ac36 broke the
noopt builder as it fails when inlining is disabled.
Since there are currently no other options at hand for checking
inlined-ness other than looking at emited symbols of the compilation,
we for now skip the problem causing test by default and only run
it on one specific builder ("linux-amd64").
Also see CL 42813, which introduced the test and contains comments
suggesting this temporary solution.
Change-Id: I3978ab0831da04876cf873d78959f821c459282b
Reviewed-on: https://go-review.googlesource.com/42820
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In the common case, the grow method only needs to reslice the internal
buffer. Making another function call to grow can be expensive when Write
is called very often with small pieces of data (like a byte or rune).
Thus, we add a tryGrowByReslice method that is inlineable so that we can
avoid an extra call in most cases.
name old time/op new time/op delta
WriteByte-4 35.5µs ± 0% 17.4µs ± 1% -51.03% (p=0.000 n=19+20)
WriteRune-4 55.7µs ± 1% 38.7µs ± 1% -30.56% (p=0.000 n=18+19)
BufferNotEmptyWriteRead-4 304µs ± 5% 283µs ± 3% -6.86% (p=0.000 n=19+17)
BufferFullSmallReads-4 87.0µs ± 5% 66.8µs ± 2% -23.26% (p=0.000 n=17+17)
name old speed new speed delta
WriteByte-4 115MB/s ± 0% 235MB/s ± 1% +104.19% (p=0.000 n=19+20)
WriteRune-4 221MB/s ± 1% 318MB/s ± 1% +44.01% (p=0.000 n=18+19)
Fixes#17857
Change-Id: I08dfb10a1c7e001817729dbfcc951bda12fe8814
Reviewed-on: https://go-review.googlesource.com/42813
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: I429637ca91f7db4144f17621de851a548dc1ce76
Reviewed-on: https://go-review.googlesource.com/34923
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Updates the s390x-specific files in these packages with the changes
to the amd64-specific files made during the review of CL 31690. I'd
like to keep these files in sync unless there is a reason to
diverge.
Change-Id: Id83e5ce11a45f877bdcc991d02b14416d1a2d8d2
Reviewed-on: https://go-review.googlesource.com/32574
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In a large codebase within Google, there are thousands of uses of:
ContainsAny|IndexAny|LastIndexAny|Trim|TrimLeft|TrimRight
An analysis of their usage shows that over 97% of them only use character
sets consisting of only ASCII symbols.
Uses of ContainsAny|IndexAny|LastIndexAny:
6% are 1 character (e.g., "\n" or " ")
58% are 2-4 characters (e.g., "<>" or "\r\n\t ")
24% are 5-9 characters (e.g., "()[]*^$")
10% are 10+ characters (e.g., "+-=&|><!(){}[]^\"~*?:\\/ ")
We optimize for ASCII sets, which are commonly used to search for
"control" characters in some string. We don't optimize for the
single character scenario since IndexRune or IndexByte could be used.
Uses of Trim|TrimLeft|TrimRight:
71% are 1 character (e.g., "\n" or " ")
14% are 2 characters (e.g., "\r\n")
10% are 3-4 characters (e.g., " \t\r\n")
5% are 10+ characters (e.g., "0123456789abcdefABCDEF")
We optimize for the single character case with a simple closured function
that only checks for that character's value. We optimize for the medium
and larger sets using a 16-byte bit-map representing a set of ASCII characters.
The benchmarks below have the following suffix name "%d:%d" where the first
number is the length of the input and the second number is the length
of the charset.
== bytes package ==
benchmark old ns/op new ns/op delta
BenchmarkIndexAnyASCII/1:1-4 5.09 5.23 +2.75%
BenchmarkIndexAnyASCII/1:2-4 5.81 5.85 +0.69%
BenchmarkIndexAnyASCII/1:4-4 7.22 7.50 +3.88%
BenchmarkIndexAnyASCII/1:8-4 11.0 11.1 +0.91%
BenchmarkIndexAnyASCII/1:16-4 17.5 17.8 +1.71%
BenchmarkIndexAnyASCII/16:1-4 36.0 34.0 -5.56%
BenchmarkIndexAnyASCII/16:2-4 46.6 36.5 -21.67%
BenchmarkIndexAnyASCII/16:4-4 78.0 40.4 -48.21%
BenchmarkIndexAnyASCII/16:8-4 136 47.4 -65.15%
BenchmarkIndexAnyASCII/16:16-4 254 61.5 -75.79%
BenchmarkIndexAnyASCII/256:1-4 542 388 -28.41%
BenchmarkIndexAnyASCII/256:2-4 705 382 -45.82%
BenchmarkIndexAnyASCII/256:4-4 1089 386 -64.55%
BenchmarkIndexAnyASCII/256:8-4 1994 394 -80.24%
BenchmarkIndexAnyASCII/256:16-4 3843 411 -89.31%
BenchmarkIndexAnyASCII/4096:1-4 8522 5873 -31.08%
BenchmarkIndexAnyASCII/4096:2-4 11253 5861 -47.92%
BenchmarkIndexAnyASCII/4096:4-4 17824 5883 -66.99%
BenchmarkIndexAnyASCII/4096:8-4 32053 5871 -81.68%
BenchmarkIndexAnyASCII/4096:16-4 60512 5888 -90.27%
BenchmarkTrimASCII/1:1-4 79.5 70.8 -10.94%
BenchmarkTrimASCII/1:2-4 79.0 105 +32.91%
BenchmarkTrimASCII/1:4-4 79.6 109 +36.93%
BenchmarkTrimASCII/1:8-4 78.8 118 +49.75%
BenchmarkTrimASCII/1:16-4 80.2 132 +64.59%
BenchmarkTrimASCII/16:1-4 243 116 -52.26%
BenchmarkTrimASCII/16:2-4 243 171 -29.63%
BenchmarkTrimASCII/16:4-4 243 176 -27.57%
BenchmarkTrimASCII/16:8-4 241 184 -23.65%
BenchmarkTrimASCII/16:16-4 238 199 -16.39%
BenchmarkTrimASCII/256:1-4 2580 840 -67.44%
BenchmarkTrimASCII/256:2-4 2603 1175 -54.86%
BenchmarkTrimASCII/256:4-4 2572 1188 -53.81%
BenchmarkTrimASCII/256:8-4 2550 1191 -53.29%
BenchmarkTrimASCII/256:16-4 2585 1208 -53.27%
BenchmarkTrimASCII/4096:1-4 39773 12181 -69.37%
BenchmarkTrimASCII/4096:2-4 39946 17231 -56.86%
BenchmarkTrimASCII/4096:4-4 39641 17179 -56.66%
BenchmarkTrimASCII/4096:8-4 39835 17175 -56.88%
BenchmarkTrimASCII/4096:16-4 40229 17215 -57.21%
== strings package ==
benchmark old ns/op new ns/op delta
BenchmarkIndexAnyASCII/1:1-4 5.94 4.97 -16.33%
BenchmarkIndexAnyASCII/1:2-4 5.94 5.55 -6.57%
BenchmarkIndexAnyASCII/1:4-4 7.45 7.21 -3.22%
BenchmarkIndexAnyASCII/1:8-4 10.8 10.6 -1.85%
BenchmarkIndexAnyASCII/1:16-4 17.4 17.2 -1.15%
BenchmarkIndexAnyASCII/16:1-4 36.4 32.2 -11.54%
BenchmarkIndexAnyASCII/16:2-4 49.6 34.6 -30.24%
BenchmarkIndexAnyASCII/16:4-4 77.5 37.9 -51.10%
BenchmarkIndexAnyASCII/16:8-4 138 45.5 -67.03%
BenchmarkIndexAnyASCII/16:16-4 241 59.1 -75.48%
BenchmarkIndexAnyASCII/256:1-4 509 378 -25.74%
BenchmarkIndexAnyASCII/256:2-4 720 381 -47.08%
BenchmarkIndexAnyASCII/256:4-4 1142 384 -66.37%
BenchmarkIndexAnyASCII/256:8-4 1999 391 -80.44%
BenchmarkIndexAnyASCII/256:16-4 3735 403 -89.21%
BenchmarkIndexAnyASCII/4096:1-4 7973 5824 -26.95%
BenchmarkIndexAnyASCII/4096:2-4 11432 5809 -49.19%
BenchmarkIndexAnyASCII/4096:4-4 18327 5819 -68.25%
BenchmarkIndexAnyASCII/4096:8-4 33059 5828 -82.37%
BenchmarkIndexAnyASCII/4096:16-4 59703 5817 -90.26%
BenchmarkTrimASCII/1:1-4 71.9 71.8 -0.14%
BenchmarkTrimASCII/1:2-4 73.3 103 +40.52%
BenchmarkTrimASCII/1:4-4 71.8 106 +47.63%
BenchmarkTrimASCII/1:8-4 71.2 113 +58.71%
BenchmarkTrimASCII/1:16-4 71.6 128 +78.77%
BenchmarkTrimASCII/16:1-4 152 116 -23.68%
BenchmarkTrimASCII/16:2-4 160 168 +5.00%
BenchmarkTrimASCII/16:4-4 172 170 -1.16%
BenchmarkTrimASCII/16:8-4 200 177 -11.50%
BenchmarkTrimASCII/16:16-4 254 193 -24.02%
BenchmarkTrimASCII/256:1-4 1438 864 -39.92%
BenchmarkTrimASCII/256:2-4 1551 1195 -22.95%
BenchmarkTrimASCII/256:4-4 1770 1200 -32.20%
BenchmarkTrimASCII/256:8-4 2195 1216 -44.60%
BenchmarkTrimASCII/256:16-4 3054 1224 -59.92%
BenchmarkTrimASCII/4096:1-4 21726 12557 -42.20%
BenchmarkTrimASCII/4096:2-4 23586 17508 -25.77%
BenchmarkTrimASCII/4096:4-4 26898 17510 -34.90%
BenchmarkTrimASCII/4096:8-4 33714 17595 -47.81%
BenchmarkTrimASCII/4096:16-4 47429 17700 -62.68%
The benchmarks added test the worst case. For IndexAny, that is when the
charset matches none of the input. For Trim, it is when the charset matches
all of the input.
Change-Id: I970874d101a96b33528fc99b165379abe58cf6ea
Reviewed-on: https://go-review.googlesource.com/31593
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Martin Möhrmann <martisch@uos.de>
In all previous versions of Go, the behavior of IndexRune(s, r)
where r was utf.RuneError was that it would effectively return the
index of any invalid UTF-8 byte sequence (include RuneError).
Optimizations made in http://golang.org/cl/28537 and
http://golang.org/cl/28546 altered this undocumented behavior such
that RuneError would only match on the RuneError rune itself.
Although, the new behavior is arguably reasonable, it did break code
that depended on the previous behavior. Thus, we add special checks
to ensure that we preserve the old behavior.
There is a slight performance hit for correctness:
benchmark old ns/op new ns/op delta
BenchmarkIndexRune/10-4 19.3 21.6 +11.92%
BenchmarkIndexRune/32-4 33.6 35.2 +4.76%
This only occurs on small strings. The performance hit for larger strings
is neglible and not shown.
Fixes#17611
Change-Id: I1d863a741213d46c40b2e1724c41245df52502a5
Reviewed-on: https://go-review.googlesource.com/32123
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In ReadRune store the size of the rune that was read into lastRead
to avoid the need to call DecodeRuneLast in UnreadRune.
fmt:
name old time/op new time/op delta
ScanInts-4 481µs ± 4% 458µs ± 3% -4.64% (p=0.000 n=20+20)
Change-Id: I500848e663a975f426402a4b3d27a541e5cac06c
Reviewed-on: https://go-review.googlesource.com/28817
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Panic if Repeat is given a negative count or
if the value of (len(*) * count) is detected
to overflow.
We panic because we cannot change the
signature of Repeat to return an error.
Fixes#16237
Change-Id: I9f5ba031a5b8533db0582d7a672ffb715143f3fb
Reviewed-on: https://go-review.googlesource.com/29954
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Don't benchmark so many sizes during the race builder's benchmark run.
This package doesn't even use goroutines.
Cuts off 10 seconds.
Updates #17104
Change-Id: Ibb2c7272c18b9014a775949c656a5b930f197cd4
Reviewed-on: https://go-review.googlesource.com/29158
Reviewed-by: David Crawshaw <crawshaw@golang.org>
IndexHard4-4 1.50ms ± 2% 0.71ms ± 0% -52.36% (p=0.000 n=20+19)
This also fixes a bug, that caused a string of length 16 to use
two 8-byte comparisons instead of one 16-byte. And adds a test for
cases when partial_match fails.
Change-Id: I1ee8fc4e068bb36c95c45de78f067c822c0d9df0
Reviewed-on: https://go-review.googlesource.com/22551
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
`bytes` and `strings` are pretty similar to each other, this commit
brings `strings` examples to its counter-part.
Partially addresses #16360
Change-Id: I551320eaa78be9df69012035f1c3333f500e04c9
Reviewed-on: https://go-review.googlesource.com/25062
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL/19862 (f79b50b8d5) recently introduced the constants
SeekStart, SeekCurrent, and SeekEnd to the io package. We should use these constants
consistently throughout the code base.
Updates #15269
Change-Id: If7fcaca7676e4a51f588528f5ced28220d9639a2
Reviewed-on: https://go-review.googlesource.com/22097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
cmd and runtime were handled separately, and I'm intentionally skipped
syscall. This is the rest of the standard library.
CL generated mechanically with github.com/mdempsky/unconvert.
Change-Id: I9e0eff886974dedc37adb93f602064b83e469122
Reviewed-on: https://go-review.googlesource.com/22104
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make package bytes consistent with strings
by adding missing function ContainsRune.
Fixes#15189
Change-Id: Ie09080b389e55bbe070c57aa3bd134053a805423
Reviewed-on: https://go-review.googlesource.com/21710
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Currently, there is no easy allocation-free way to turn a
[]byte or string into an io.Reader. Thus, we add a Reset method
to bytes.Reader and strings.Reader to allow the reuse of these
Readers with another []byte or string.
This is consistent with the fact that many standard library io.Readers
already support a Reset method of some type:
bufio.Reader
flate.Reader
gzip.Reader
zlib.Reader
debug/dwarf.LineReader
bytes.Buffer
crypto/rc4.Cipher
Fixes#15033
Change-Id: I456fd1af77af6ef0b4ac6228b058ac1458ff3d19
Reviewed-on: https://go-review.googlesource.com/21386
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This function is present in the strings package but missing from bytes,
and we would like to keep the two packages consistent.
Add it to bytes, and copy the test over as well.
Fixes#15140
Change-Id: I5dbd28da83a9fe741885794ed15f2af2f826cb3c
Reviewed-on: https://go-review.googlesource.com/21562
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The fmt package does not use bytes.Buffer
anymore as an internal buffer.
Change-Id: I34c7a52506290ccbcb10ea2e85dea49a0a8b8203
Reviewed-on: https://go-review.googlesource.com/20511
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.
Go policy has been single space after periods in comments for some time.
The copyright header template at:
https://golang.org/doc/contribute.html#copyright
also uses a single space.
Make them all consistent.
Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Named returned values should only be used on public funcs and methods
when it contributes to the documentation.
Named return values should not be used if they're only saving the
programmer a few lines of code inside the body of the function,
especially if that means there's stutter in the documentation or it
was only there so the programmer could use a naked return
statement. (Naked returns should not be used except in very small
functions)
This change is a manual audit & cleanup of public func signatures.
Signatures were not changed if:
* the func was private (wouldn't be in public godoc)
* the documentation referenced it
* the named return value was an interesting name. (i.e. it wasn't
simply stutter, repeating the name of the type)
There should be no changes in behavior. (At least: none intended)
Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109
Reviewed-on: https://go-review.googlesource.com/20024
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
REP-prefixed instructions have a large startup cost.
Avoid them like the plague.
benchmark old ns/op new ns/op delta
BenchmarkIndexByte10-8 22.4 5.34 -76.16%
Fixes#13983
Change-Id: I857e956e240fc9681d053f2584ccf24c1b272bb3
Reviewed-on: https://go-review.googlesource.com/18703
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently the packages have the following index functions:
func Index(s, sep []byte) int
func IndexAny(s []byte, chars string) int
func IndexByte(s []byte, c byte) int
func IndexFunc(s []byte, f func(r rune) bool) int
func IndexRune(s []byte, r rune) int
func LastIndex(s, sep []byte) int
func LastIndexAny(s []byte, chars string) int
func LastIndexFunc(s []byte, f func(r rune) bool) int
Searching for the last occurrence of a byte is quite common
for string parsing algorithms (e.g. find the last paren on a line).
Also addition of LastIndexByte makes the set more orthogonal.
Change-Id: Ida168849acacf8e78dd70c1354bef9eac5effafe
Reviewed-on: https://go-review.googlesource.com/9500
Reviewed-by: Rob Pike <r@golang.org>
As noted on recently on golang-nuts, there's currently no way to know
the total size of a strings.Reader or bytes.Reader when using ReadAt
on them. Most callers resort to wrapping it in an io.SectionReader to
retain that information.
The SizeReaderAt abstraction (an io.ReaderAt with a Size() int64
method) has proven useful as a way of expressing a concurrency-safe
read-only number of bytes.
As one example, see http://talks.golang.org/2013/oscon-dl.slide#49 and
the rest of that presentation for its use in dl.google.com.
SizeReaderAt is also used in the open source google-api-go-client, and
within Google's internal codebase, where it exists in a public package
created in 2013 with the package comment: "These may migrate to the
standard library after we have enough experience with their feel."
I'm still as happy with the SizeReaderAt abstraction and its
composabilty as I was in 2013, so I'd like to make these two Readers
also be SizeReaderAts.
Fixes#9667
Change-Id: Ie6f145ada419dd116280472d8c029f046d5edf70
Reviewed-on: https://go-review.googlesource.com/3199
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The the has been deleted.
Change-Id: I4290105435d4f1fd10c7014f913a3147ddeb3c2b
Reviewed-on: https://go-review.googlesource.com/8469
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Obtaining the actual size of the underlying storage of the buffer can
be very useful in various scenarios. Long running programs which write
and read large amounts of data to buffers might have to recycle
buffers in order to avoid holding onto potentially huge buffers.
For example, a piece of code which buffers a lot of data in a buffer
might need to release the big buffer and start again with a smaller
buffer after it finished processing the huge amount of data.
In cases where pools of bytes.Buffer are used, being able to check the
size of the allocated data can be very useful.
Instead of forking bytes.Buffer or writing new code, we can export the
Cap() method.
Change-Id: I79d4f0a3cff53b9419d82c8122964761e9e38566
Reviewed-on: https://go-review.googlesource.com/8342
Reviewed-by: Rob Pike <r@golang.org>
Regular expression noteMarker requires the definition of a (who) section
when reading note from a sequence of comments.
Change-Id: I9635de9b86f00d20ec108097fee4d4a8f76237b2
Reviewed-on: https://go-review.googlesource.com/1952
Reviewed-by: Russ Cox <rsc@golang.org>
Not sure why they used empty.s and all these other
packages were special cased in cmd/go instead.
Add them to the list.
This avoids problems with net .s files being compiled
with gcc in cgo mode and gcc not supporting // comments
on ARM.
Not a problem with bytes, but be consistent.
The last change fixed the ARM build but broke the Windows build.
Maybe *this* will make everyone happy. Sigh.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/144530046
Daniel Martí
Russ Cox
Keith Randall
Keith Randall
Ian Lance Taylor
Javier Segura
Afanasev Stanislav
Gabriel Aszalos
Tim Cooper
Andrzej Żeżel
Borja Clemente
Michael Brandenburg
Marvin Stenger
Bryan C. Mills
Martin Möhrmann
Brian Downs
Alberto Donizetti
Robert Griesemer
Josselin Costanzi
Eric Lagergren
Carlo Alberto Ferraris
Aliaksandr Valialkin
Ilya Tocar
shawnps
Michael Munday
Joe Tsai
Martin Möhrmann
Emmanuel Odeke
Brad Fitzpatrick
Hiroshi Ioka
Carlos C
Marcel van Lohuizen
Matthew Dempsky
Rob Pike
Dominik Honnef
Josh Bleecher Snyder
Uttam C Pawar
Alan Donovan
Dmitry Vyukov
Cristian Staretu
Dave Cheney
areski