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>
Use only reflect.TypeOf to detect if argument is a string.
The wasString return is only needed in doPrint with the 'v' verb.
This type of string detection is handled correctly by reflect.TypeOf
which is used already in doPrint for identifying a string argument.
Remove now obsolete wasString computations and return values.
Change-Id: Iea2de7ac0f5c536a53eec63f7e679d628f5af8dc
Reviewed-on: https://go-review.googlesource.com/19976
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@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>
Do not replace the sign in front of a number with a space if both
f.space and f.plus are both specified for number formatting.
This was already the case for integers but not for floats
and complex numbers.
Updates: #14543.
Change-Id: I07ddeb505003db84a8a7d2c743dc19fc427a00bd
Reviewed-on: https://go-review.googlesource.com/19974
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@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>
Move the decision if zero padding is allowed to doPrintf
where the other formatting decisions are made.
Removes some dead code for negative f.wid that was never used
due to f.wid always being positive and f.minus deciding if left
or right padding should be used.
New padding code writes directly into the buffer and is as fast
as the old version but avoids the cost of needing package init.
name old time/op new time/op delta
SprintfPadding-2 246ns ± 5% 245ns ± 4% ~ (p=0.345 n=50+47)
Change-Id: I7dfddbac8e328f4ef0cdee8fafc0d06c784b2711
Reviewed-on: https://go-review.googlesource.com/19957
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Makes zero padding of NaN and infinities consistent
by using spaces instead of zeroes to pad NaN.
Adds more tests for NaN formatting.
Fixes#14421
Change-Id: Ia20f8e878cc81ac72a744ec10d65e84b94e09c6a
Reviewed-on: https://go-review.googlesource.com/19723
Reviewed-by: Rob Pike <r@golang.org>
Remove floating point comparisons and rely only on the information
directly provided by appendFloat.
Make restoring the zero padding flag explicit instead of using a defer.
Rearrange some case distinctions to remove duplicated code.
Add more test cases for zero padded floating point numbers with sign.
benchmark old ns/op new ns/op delta
BenchmarkSprintfFloat-4 187 180 -3.74%
Change-Id: Ifa2ae85257909f40b1b18118c92b516933271729
Reviewed-on: https://go-review.googlesource.com/19721
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>
Factor out duplicated race thunks from sync, syscall net
and fmt packages into a separate package and use it.
Fixes#8593
Change-Id: I156869c50946277809f6b509463752e7f7d28cdb
Reviewed-on: https://go-review.googlesource.com/14870
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@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>
fmt docs say:
If the operand is a reflect.Value, the concrete value it
holds is printed as if it was the operand.
It implies recursive application of this rule, which is not the case.
Clarify the docs.
Change-Id: I019277c7c6439095bab83e5536aa06403638aa51
Reviewed-on: https://go-review.googlesource.com/15952
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The construction
fmt.Printf("%*d", n, 4)
reads the argument n as a width specifier to use when printing 4.
Until now, only strict int type was accepted here and it couldn't
be fixed because the fix, using reflection, broke escape analysis
and added an extra allocation in every Printf call, even those that
do not use this feature.
The compiler has been fixed, although I am not sure when exactly,
so let's fix Printf and then write
Fixes#10732.
Change-Id: I79cf0c4fadd876265aa39d3cb62867247b36ab65
Reviewed-on: https://go-review.googlesource.com/14491
Reviewed-by: Ian Lance Taylor <iant@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>
Also improve the documentation. A prior fix in this release
changed the properties for empty strings and slices, incorrectly.
Previous behavior is now restored and better documented.
Add lots of tests.
The behavior is that when using a string-like format (%s %q %x %X)
a byte slice is equivalent to a string, and printed as a unit. The padding
applies to the entire object. (The space and sharp flags apply
elementwise.)
Fixes#11422.
Fixes#10430.
Change-Id: I758f0521caf71630437e43990ec6d6c9a92655e3
Reviewed-on: https://go-review.googlesource.com/11600
Reviewed-by: Russ Cox <rsc@golang.org>
Negative width arguments now left align the way a minus-width in the
format string aligns. The minus in the format string overrides the sign
of the argument as in C.
Precision behavior is modified to include an error if the argument is
negative. This differs from a negative precision in a format string
which just terminates the format.
Additional checks for large magnitude widths and precisions are added to
make the runtime behavior (failure, but with different error messages),
more consistent between format string specified width/precision and
argument specified width/precision.
Fixes#11376
Change-Id: I8c7ed21088e9c18128a45d4c487c5ab9fafd13ef
Reviewed-on: https://go-review.googlesource.com/11405
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@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>
Allow room for the initial minus sign of negative integers when
computing widths.
Fixes#10945.
Change-Id: I04d80203aaff64611992725d613ec13ed2ae721f
Reviewed-on: https://go-review.googlesource.com/10393
Reviewed-by: Rob Pike <r@golang.org>
The code already handled high widths but not high precisions.
Also make sure it handles the harder cases of %U.
Fixes#10745.
Change-Id: Ib4d394d49a9941eeeaff866dc59d80483e312a98
Reviewed-on: https://go-review.googlesource.com/9769
Reviewed-by: Ian Lance Taylor <iant@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>
The old one was inferior.
Fixes#10695.
Change-Id: Ia7fb88c9ceb1b10197b77a54f729865385288d98
Reviewed-on: https://go-review.googlesource.com/9709
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
When a reflect.Value is passed to Printf (etc.), fmt called the
String method, which does not disclose its contents. To get the
contents, one could call Value.Interface(), but that is illegal
if the Value is not exported or otherwise forbidden.
This CL improves the situation with a trivial change to the
fmt package: when we see a reflect.Value as an argument,
we treat it exactly as we treat a reflect.Value we make inside
the package. This means that we always print the
contents of the Value as if _that_ was the argument to Printf.
This is arguably a breaking change but I think it is a genuine
improvement and no greater a break than many other tweaks
we have made to formatted output from this package.
Fixes#8965.
Change-Id: Ifc2a4ce3c1134ad5160e101d2196c22f1542faab
Reviewed-on: https://go-review.googlesource.com/8731
Reviewed-by: roger peppe <rogpeppe@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
The documentation is clear that formats like %02x applied to a
byte slice are per-element, so the result should be nothing if the
slice is empty. It's not, because the top-level padding routine is called.
It shouldn't be: the loop does the padding for us.
Fixes#10430.
Change-Id: I04ea0e804c0f2e70fff3701e5bf22acc90e890da
Reviewed-on: https://go-review.googlesource.com/8864
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The tests in the basic string section are now covering more code paths
for encoding a string into the hexadecimal representation of its bytes.
Changed the basic string and basic bytes tests so that they mirror each other.
Change-Id: Ib5dc7b33876769965f9aba2ac270040abc4b2451
Reviewed-on: https://go-review.googlesource.com/2611
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
If a method called by fmt triggers a panic, the output usually says
so. However, there is heretofore undocumented special treatment for
a panic caused by formatting a nil value with an Error or String
method: the output is simply "<nil>". Document that behavior.
Change-Id: Id0f79dd0b3487f9d1c74a0856727bba5cc342be4
Reviewed-on: https://go-review.googlesource.com/6410
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Currently we always allocate string buffers in heap.
For example, in the following code we allocate a temp string
just for comparison:
if string(byteSlice) == "abc" { ... }
This change extends escape analysis to cover []byte->string
conversions and string concatenation. If the result of operations
does not escape, compiler allocates a small buffer
on stack and passes it to slicebytetostring and concatstrings.
Then runtime uses the buffer if the result fits into it.
Size of the buffer is 32 bytes. There is no fundamental theory
behind this number. Just an observation that on std lib
tests/benchmarks frequency of string allocation is inversely
proportional to string length; and there is significant number
of allocations up to length 32.
benchmark old allocs new allocs delta
BenchmarkFprintfBytes 2 1 -50.00%
BenchmarkDecodeComplex128Slice 318 316 -0.63%
BenchmarkDecodeFloat64Slice 318 316 -0.63%
BenchmarkDecodeInt32Slice 318 316 -0.63%
BenchmarkDecodeStringSlice 2318 2316 -0.09%
BenchmarkStripTags 11 5 -54.55%
BenchmarkDecodeGray 111 102 -8.11%
BenchmarkDecodeNRGBAGradient 200 188 -6.00%
BenchmarkDecodeNRGBAOpaque 165 152 -7.88%
BenchmarkDecodePaletted 319 309 -3.13%
BenchmarkDecodeRGB 166 157 -5.42%
BenchmarkDecodeInterlacing 279 268 -3.94%
BenchmarkGoLookupIP 153 135 -11.76%
BenchmarkGoLookupIPNoSuchHost 508 466 -8.27%
BenchmarkGoLookupIPWithBrokenNameServer 245 226 -7.76%
BenchmarkClientServerParallel4 62 61 -1.61%
BenchmarkClientServerParallel64 62 61 -1.61%
BenchmarkClientServerParallelTLS4 79 78 -1.27%
BenchmarkClientServerParallelTLS64 112 111 -0.89%
benchmark old ns/op new ns/op delta
BenchmarkFprintfBytes 381 311 -18.37%
BenchmarkStripTags 2615 2351 -10.10%
BenchmarkDecodeNRGBAGradient 3715887 3635096 -2.17%
BenchmarkDecodeNRGBAOpaque 3047645 2928644 -3.90%
BenchmarkGoLookupIP 153 135 -11.76%
BenchmarkGoLookupIPNoSuchHost 508 466 -8.27%
Change-Id: I9ec01da816945c3329d7be3c7794b520418c3f99
Reviewed-on: https://go-review.googlesource.com/3120
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@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>
It was inconsistent.
Also test these better.
Also document the default format for types.
This wasn't written down.
Fixes#8470.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/154870043
Apply a similar transformation to %+v that we did to %#v, making it
a top-level setting separate from the + flag itself. This fixes the
appearance of flags in Formatters and cleans up the code too,
probably making it a little faster.
Fixes#8835.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/154820043
The %#v verb is special: it says all values below need to print as %#v.
However, for some situations the # flag has other meanings and this
causes some issues, particularly in how Formatters work. Since %#v
dominates all formatting, translate it into actual state of the formatter
and decouple it from the # flag itself within the calculations (although
it must be restored when methods are doing the work.)
The result is cleaner code and correct handling of # for Formatters.
TODO: Apply the same thinking to the + flag in a followup CL.
Also, the wasString return value in handleMethods is always false,
so eliminate it.
Update #8835
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/146650043
This thing should never be called, but before
151960044 it was being called, incorrectly.
This is now just a precaution but let's pretend it
Fixes#8843
even though that was fixed by 151960044.
The test case was already there and ran, another mystery.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/151970043
