Instead use string(r) where r has type rune.
This is in preparation for a vet warning for string(i).
Updates #32479
Change-Id: Ic205269bba1bd41723950219ecfb67ce17a7aa79
Reviewed-on: https://go-review.googlesource.com/c/go/+/220844
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Akhil Indurti <aindurti@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Toshihiro Shiino <shiino.toshihiro@gmail.com>
There were a couple of bugs, including not requiring a percent and
returning the wrong error for a bad format containing %%.
Both are addressed by fixing the first.
Fixes#34180.
Change-Id: If96c0c0258bcb95eec49871437d719cb9d399d9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/202879
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Renaming the method makes clear, both to readers and to vet,
that this method is not the implementation of io.ByteWriter.
Working toward making the tree vet-safe instead of having
so many exceptions in cmd/vet/all/whitelist.
For #31916.
Change-Id: I79da062ca6469b62a6b9e284c6cf2413c7425249
Reviewed-on: https://go-review.googlesource.com/c/go/+/176109
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 165619 removed these names when it removed
the use of the plain 'return'. But the names help for
documentation purposes even without being mentioned
directly in the function, so removing them makes the
code less readable. Put them back. I renamed found
to zeroFound to make the meaning clearer.
Change-Id: I1010931f08290af0b0ede7d21b1404c2eea196a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/165899
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL updates fmt's scanner to accept the new number syntaxes:
- Hexadecimal floating-point values.
- Digit-separating underscores.
- Leading 0b and 0o prefixes.
See golang.org/design/19308-number-literals for background.
For #12711.
For #19308.
For #28493.
For #29008.
Change-Id: I5582af5c94059c781e6cf4e862441d3df3006adf
Reviewed-on: https://go-review.googlesource.com/c/160247
Reviewed-by: Robert Griesemer <gri@golang.org>
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/52890
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
This CL makes minor adjustment to the handling of spaces and newlines
and then documents the result.
The semantic adjustment mainly concerns the handling of a run of
spaces following a newline in the format, like in "\n ".
Previously, that run of spaces was ignored entirely, leading to paradoxes
like the format "1 \n 2" not matching itself as input.
Now, spaces following a newline in the format match zero or more
spaces following the corresponding newline in the input.
The changes to the test suite show how minor the semantic adjustments are
and how they make the behavior more regular than previously.
This CL also updates the documentation to explain the handling of
spaces more precisely, incorporating the draft from CL 17723 but
describing the newly introduced behavior.
Fixes#13565.
Change-Id: I129666e9ba42de3c28b67f75cb47488e9a4c1867
Reviewed-on: https://go-review.googlesource.com/30611
Reviewed-by: Rob Pike <r@golang.org>
Change https://golang.org/cl/19895 caused a regression
where the last character in a string would be dropped if it was
accompanied by an io.EOF.
This change fixes the logic so that the last byte is still returned
without a problem.
Fixes#16393
Change-Id: I7a4d0abf761c2c15454136a79e065fe002d736ea
Reviewed-on: https://go-review.googlesource.com/24981
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Use constants instead of dynamically computed values to determine
the bit sizes of types similar to how strconv and other packages
directly compute these sizes. Move these constants near the code
that uses them.
Change-Id: I78d113b7e697466097e32653975df5990380c2c1
Reviewed-on: https://go-review.googlesource.com/20514
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@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>
Once upon a time fmt did use bytes.Buffer for its buffer.
The buffer write methods still mimic the bytes.Buffer signatures.
The current code depends on manipulating the buffer []bytes array directly
which makes going back to bytes.Buffer by only changing the type of buffer
impossible. Since type buffer is not exported the methods can be simplified
to the needs of fmt. This saves space and avoids unnecessary overhead.
Use WriteString instead of Write for known inputs since
WriteString is faster than Write to append the same data.
This also saves space in the binary.
Remove the add method from Printer and depending on the data to be written
use WriteRune or WriteByte directly instead.
In total makes the go binary around 4 kilobyte smaller.
name old time/op new time/op delta
SprintfEmpty-2 24.1ns ± 3% 23.8ns ± 1% -1.14% (p=0.000 n=20+20)
SprintfString-2 114ns ± 2% 114ns ± 4% ~ (p=0.558 n=20+19)
SprintfInt-2 116ns ± 9% 118ns ± 7% ~ (p=0.086 n=20+20)
SprintfIntInt-2 195ns ± 6% 193ns ± 5% ~ (p=0.345 n=20+19)
SprintfPrefixedInt-2 251ns ±16% 241ns ± 9% -3.69% (p=0.024 n=20+19)
SprintfFloat-2 203ns ± 4% 205ns ± 5% ~ (p=0.153 n=20+20)
SprintfBoolean-2 101ns ± 7% 96ns ±11% -5.23% (p=0.005 n=19+20)
ManyArgs-2 651ns ± 7% 628ns ± 7% -3.44% (p=0.002 n=20+20)
FprintInt-2 164ns ± 2% 158ns ± 2% -3.62% (p=0.000 n=20+18)
FprintfBytes-2 215ns ± 1% 216ns ± 1% +0.58% (p=0.000 n=20+20)
FprintIntNoAlloc-2 115ns ± 0% 112ns ± 0% -2.61% (p=0.000 n=20+20)
ScanInts-2 700µs ± 0% 702µs ± 1% +0.38% (p=0.000 n=18+20)
ScanRecursiveInt-2 82.7ms ± 0% 82.7ms ± 0% ~ (p=0.820 n=20+20)
Change-Id: I0409eb170b8a26d9f4eb271f6292e5d39faf2d8b
Reviewed-on: https://go-review.googlesource.com/19955
Reviewed-by: Rob Pike <r@golang.org>
All io.Reader that are passed to newScanState in all the standard
library tests that implement io.RuneReader also implement io.RuneScanner.
Do not check on each call ScanState's UnreadRune that the used RuneReader
also implements the UnreadRune method by using a private interface.
Instead require the used Reader to implement the public RuneScanner
interface.
The extra implementation logic for UnreadRune is removed from ScanState.
Instead the readRune wrapper is extended to implement UnreadRune for the
RuneScanner interface. If the Reader passed to newScanstate does not
implement RuneScanner the readRune wrapper is used to implement the
missing functionality.
Note that a RuneReader that does not implement RuneScanner will also
be wrapped by runeRead which was not the case before.
Performance with the readRune wrapper is better than without before.
Add benchmark to compare performance with and without using the
readRune wrapper.
name old time/op new time/op delta
ScanInts-2 704µs ± 0% 615µs ± 1% -12.73% (p=0.000 n=20+20)
ScanRecursiveInt-2 82.6ms ± 0% 51.4ms ± 0% -37.71% (p=0.000 n=20+20)
ScanRecursiveIntReaderWrapper-2 85.1ms ± 0% 52.4ms ± 0% -38.36% (p=0.000 n=20+20)
Change-Id: I8c6e85db9b87a8171caab12f020b6e256b498e81
Reviewed-on: https://go-review.googlesource.com/19895
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This change can break real code. There are other newline-related bugs in this code, and fixing them will also break real code. If we're going to break real code, let's fix all the bugs together and just break things once.
This reverts commit 8331f19d97.
Change-Id: Ie4b3022f3a305c3e1f78cc208e50beed212608e6
Reviewed-on: https://go-review.googlesource.com/17724
Reviewed-by: Rob Pike <r@golang.org>
Sscanf doc says:
Newlines in the input must match newlines in the format.
However Sscanf didn't check newline in the end of input (EOF).
A test for the case is broken.
* check newline in EOF
* fix the test
* slightly simplify ss.doScanf
Fixes#12788
Change-Id: Iaf6b7d81324a72e557543ac22ecea5cecb72e0d6
Reviewed-on: https://go-review.googlesource.com/16165
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Previously it said, "bad verb %% for ...", which is not only wrong,
it's ironic as the fix is to use %% rather than % at the end of the
string. Diagnose the case where a simple % is at EOF.
If there's anything after the percent, the error is already good
but this CL also puts quotes around the verb designation ('%d' etc.)
to make it even clearer, especially when there is a space involved.
Fixes#12315.
Change-Id: I31d30659965e940d0bd9ce92a475aab3e2369ef0
Reviewed-on: https://go-review.googlesource.com/17150
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For printing, the format verb '%X' results in a capitalized
hex-representation of the formatted value. Conversely, using
'%X' in a Scanf function should scan a hex-representation
into the given interface{}. The existing implementation
however only supports '%X' for scanning hex values into
integers; strings or byte slices remain empty. On the other
hand, lower-case '%x' supports strings and byte slices just
fine. This is merely an oversight, which this commit fixes.
(Additional tests also included.)
Fixes#12940
Change-Id: I178a7f615bae950dfc014ca8c0a038448cf0452a
Reviewed-on: https://go-review.googlesource.com/15689
Reviewed-by: Andrew Gerrand <adg@golang.org>
In short, %c should just give you the next rune, period.
Apparently this is the design. I use the term loosely.
Fixes#12275
Change-Id: I6f30bed442c0e88eac2244d465c7d151b29cf393
Reviewed-on: https://go-review.googlesource.com/13821
Reviewed-by: Andrew Gerrand <adg@golang.org>
When scanning a hex byte at EOF, the code was ungetting the eof,
which backed up the input and caused double-scanning of a byte.
Delete the call to UnreadRune.
This line appeared in 1.5 for some reason; it was not in 1.4 and
should be removed again for 1.5
Fixes#12090.
Change-Id: Iad1ce8e7db8ec26615c5271310f4b0228cca7d78
Reviewed-on: https://go-review.googlesource.com/13461
Reviewed-by: Andrew Gerrand <adg@golang.org>
When scanning with a width, as in %5s, C skips leading spaces
brefore counting the 5 characters. We should do the same.
Reword the documentation about widths to make this clear.
Fixes#9444
Change-Id: I443a6441adcf1c834057ef3977f9116a987a79cd
Reviewed-on: https://go-review.googlesource.com/10997
Reviewed-by: Andrew Gerrand <adg@golang.org>
The documentation says that newlines behave like this:
Scan etc.: newlines are spaces.
Scanln etc.: newlines terminate the scan.
Scanf etc.: newlines must match in input and format.
The code did not implement this behavior in all cases,
especially for Scanf. Make it behave:
- Fix the handling of spaces and newlines in ss.Advance.
The code is longer but now behaves as it should.
- Delete the reuse of the current ss in newScanState.
There is really no need, since it's only used in recursive
calls to Scan etc., and the flags are likely wrong. Simpler
just to allocate a new one every time, and likelier to
be correct.
Fixes#10862.
Change-Id: If060ac021017346723b0d62de4e5a305da898f68
Reviewed-on: https://go-review.googlesource.com/10991
Reviewed-by: Andrew Gerrand <adg@golang.org>
No semantic change.
Fixes#8708.
Change-Id: Ieda04a86a19bb69bfc2519d381a2f025e7cb8279
Reviewed-on: https://go-review.googlesource.com/9740
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Couldn't handle a hex string terminated by anything
other than spaces. Easy to fix.
Fixes#9124.
Change-Id: I18f89a0bd99a105c9110e1ede641873bf9daf3af
Reviewed-on: https://go-review.googlesource.com/1538
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
