Like panicking and erroring - wrapErrs should always be reset to
the default false. wrapErrs should only be true when set by Errorf.
Change-Id: I4d51cc2f0905109e232b0983dc5331bd34f138bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/178517
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When fmt.Errorf is provided with a %w verb with an error operand,
return an error implementing an Unwrap method returning that operand.
It is invalid to use %w with other formatting functions, to use %w
multiple times in a format string, or to use %w with a non-error
operand. When the Errorf format string contains an invalid use of %w,
the returned error does not implement Unwrap.
Change-Id: I534e20d3b163ab22c2b137b1c9095906dc243221
Reviewed-on: https://go-review.googlesource.com/c/go/+/176998
Reviewed-by: Marcel van Lohuizen <mpvl@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>
As proposed in Issue #29934, update errors produced by the os package to
work with errors.Is sentinel tests. For example,
errors.Is(err, os.ErrPermission) is equivalent to os.IsPermission(err)
with added unwrapping support.
Move the definition for os.ErrPermission and others into the syscall
package. Add an Is method to syscall.Errno and others. Add an Unwrap
method to os.PathError and others.
Updates #30322
Updates #29934
Change-Id: I95727d26c18a5354c720de316dff0bffc04dd926
Reviewed-on: https://go-review.googlesource.com/c/go/+/163058
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
The name change init -> init.ializers was initially required for
initialization code.
With CL 161337 there's no wrapper code any more, there's a data
structure instead (named .inittask). So we can go back to just
plain init appearing in tracebacks.
RELNOTE=yes
Update #29919. Followon to CL 161337.
Change-Id: I5a4a49d286df24b53b2baa193dfda482f3ea82a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/167780
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This applies only for cases where %w is not used.
The purpose of this change is to reduce test failures where tests
depend on these two being the same type, as they previously were.
Change-Id: I2dd28b93fe1d59f3cfbb4eb0875d1fb8ee699746
Reviewed-on: https://go-review.googlesource.com/c/go/+/167402
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This is a refinement of CL 164557.
Make it explicit in tests that using a non-string verb with
fmtError does not result in falling back to using fmt.Formatter.
Change-Id: I6d090f31818eb7cc7668d7565b1449c91cd03a23
Reviewed-on: https://go-review.googlesource.com/c/go/+/164701
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
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>
When formatting an error with a non-string formatting verb such as %d,
use the default formatting behavior rather than treating this as a bad
verb.
For example, this should print 42, not %!d(main.E=42):
var E int
func (E) Error() string { return "error" }
fmt.Printf("%d", E(42))
Fixes#30472
Change-Id: I62fd309c8ee9839a69052b0ec7f1808449dcee8e
Reviewed-on: https://go-review.googlesource.com/c/164557
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Original Printf("%d", hi) obviously doesn't produce
%!d(string=hi) unless somewhere before this code
block you have hi := "hi" somewhere, also this change
maintains consistency with the rest of it
Change-Id: I40d8cca623176dcad66374ba74e3a1f8f975ac9e
GitHub-Last-Rev: 242e9ee6af
GitHub-Pull-Request: golang/go#30223
Reviewed-on: https://go-review.googlesource.com/c/162541
Reviewed-by: Brad Fitzpatrick <bradfitz@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 CL modifies fmt's printer to implement %#b and %O
to emit leading 0b and 0o prefixes on binary and octal.
(%#o is already taken and emits "0377"; %O emits "0o377".)
See golang.org/design/19308-number-literals for background.
For #19308.
For #12711.
Vet update is #29986.
Change-Id: I7c38a4484c48a03abe9f6d45c7d981c7c314f583
Reviewed-on: https://go-review.googlesource.com/c/160246
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This CL modifies fmt's printer to implement %x and %X
for formatting floating-point data (floats and complexes)
in standard hexadecimal notation.
See golang.org/design/19308-number-literals for background.
For #29008.
Vet update is #29986.
Change-Id: If2842a11631bc393a1ebcf6914ed07658652af5a
Reviewed-on: https://go-review.googlesource.com/c/160245
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Now that maps are printed in deterministic order, the map example
can have multiple keys without breaking the build.
Change-Id: Iccec0cd76a3d41c75d8d4eb768ec0ac09ad9f2ad
Reviewed-on: https://go-review.googlesource.com/c/151218
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
fmtBytes is in the top 10 callers of runtime.slicebytetostring according
to Google wide profiling data.
Avoid the string conversion of the input byte slice in fmtBytes by calling
a newly added specialized fmtS function for byte slices.
Expand tests for verb s with widths to test strings and byte slice arguments.
SprintfTruncateString 157ns ± 4% 156ns ± 3% ~ (p=0.122 n=20+20)
SprintfTruncateBytes 188ns ± 2% 155ns ± 3% -18.00% (p=0.000 n=20+19)
name old alloc/op new alloc/op delta
SprintfTruncateString 16.0B ± 0% 16.0B ± 0% ~ (all equal)
SprintfTruncateBytes 64.0B ± 0% 16.0B ± 0% -75.00% (p=0.000 n=20+20)
name old allocs/op new allocs/op delta
SprintfTruncateString 1.00 ± 0% 1.00 ± 0% ~ (all equal)
SprintfTruncateBytes 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=20+20)
Change-Id: I461bf514d4232b39bd9c812f7faa4e5ef693a03b
Reviewed-on: https://go-review.googlesource.com/c/145284
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
For easier testing, change the way maps are printed so they
appear in a consistent order between runs. Do this by printing
them in key-sorted order.
To do this, we add a package at the root, internal/fmtsort,
that implements a general mechanism for sorting map keys
regardless of their type. This is a little messy and probably
slow, but formatted printing of maps has never been fast and
is already always reflection-driven.
The rules are:
The ordering rules are more general than with Go's < operator:
- when applicable, nil compares low
- ints, floats, and strings order by <
- NaN compares less than non-NaN floats
- bool compares false before true
- complex compares real, then imag
- pointers compare by machine address
- channel values compare by machine address
- structs compare each field in turn
- arrays compare each element in turn.
- interface values compare first by reflect.Type describing the concrete type
and then by concrete value as described in the previous rules.
The new package is internal because we really do not want
everyone using this to sort things. It is slow, not general, and
only suitable for the subset of types that can be map keys.
Also use the package in text/template, which already had a
weaker version of this mechanism.
This change requires adding a dependency on sort to the fmt
package, but that isn't disruptive to the dependency tree.
Fixes#21095
Change-Id: Ia602115c7de5d95993dbd609611d8bd96e054157
Reviewed-on: https://go-review.googlesource.com/c/142737
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Numbers without decimals are valid Go representations of whole-number
floats. That is, "var x float64 = 5" is valid Go. Avoid breakage in
tests that expect a certain output from %#v by reverting to it.
To guarantee the right type is generated by a print use %T(%#v) instead.
Added a test to lock in this behavior.
This reverts commit 7c7cecc184.
Fixes#27634
Updates #26363
Change-Id: I544c400a0903777dd216452a7e86dfe60b0b0283
Reviewed-on: https://go-review.googlesource.com/c/142597
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
And start using it elsewhere in the standard library, removing the
copies in the process.
While at it, rewrite the io.WriteString godoc to be more clear, since it
can now make reference to the defined interface.
Fixes#27946.
Change-Id: Id5ba223c09c19e5fb49815bd3b1bd3254fc786f3
Reviewed-on: https://go-review.googlesource.com/c/139457
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Provide an example for each of the printing functions (Print,
Sprintf, Fprintln etc.), and make them all produce the same output
so their usage can be compared.
Also add a package-level example explaining the difference between
how Printf, Println, and Print behave.
There are more examples to come.
Update #27554.
Change-Id: Ide03e5233f3762a9ee2ac0269f534ab927562ce2
Reviewed-on: https://go-review.googlesource.com/136615
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There is much left out here—the space of possibilities is very
large—but this example shows all that most programmers will need
to know for most printing problems.
Update #27554.
Change-Id: Ib6ae651d5c3720cf7fe1a05ffd0859a5b56a9157
Reviewed-on: https://go-review.googlesource.com/136616
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current usage of sync.Pool is leaky because it stores an arbitrary
sized buffer into the pool. However, sync.Pool assumes that all items in the
pool are interchangeable from a memory cost perspective. Due to the unbounded
size of a buffer that may be added, it is possible for the pool to eventually
pin arbitrarily large amounts of memory in a live-lock situation.
As a simple fix, we just set a maximum size that we permit back into the pool.
We do not need to fix the use of a sync.Pool in scan.go since the free method
has always enforced a maximum capacity since the first commit of the scan logic.
Fixes#27740
Updates #23199
Change-Id: I875278f7dba42625405df36df3e9b028252ce5e3
Reviewed-on: https://go-review.googlesource.com/136116
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Updates #27376
Change-Id: I9ce6541a95b5ecd13f3932558427de1f597df07a
Reviewed-on: https://go-review.googlesource.com/134036
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #27376
Change-Id: I2fa63b0d1981a419626072d985e6f3326f6013ff
Reviewed-on: https://go-review.googlesource.com/134035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #27376
Change-Id: I0ceb672a9fcd7bbf491be1577d7f135ef35b2561
Reviewed-on: https://go-review.googlesource.com/133455
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: Ifd509c0c6a6ea41094b6ae1f4931414325b152fd
Reviewed-on: https://go-review.googlesource.com/132475
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
"someting" is misspelled and the error handling both clobbers the
error that occurs and distracts from the point of the example, which
is to demonstrate how Printf works. It's better to just panic with the
error.
Change-Id: I5fb0a4a1a8b4772cbe0302582fa878d95e3a4060
Reviewed-on: https://go-review.googlesource.com/132376
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The errors package has an example for Errorf, but the fmt
package does not. Copy the Errorf example from errors to
fmt. Move existing Stringer example into separate file, so as
not to break the assumption that the entire file will be
presented as the example.
Change-Id: I8a210a69362017fa08615a8c3feccdeee8427e22
Reviewed-on: https://go-review.googlesource.com/132239
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes the unwanted behaviour where printing a zero float with the
#v fmt verb outputs "0" - e.g. missing the trailing decimal. This means
that the output would be interpreted as an int rather than a float when
parsed as Go source. After this change the the output is "0.0".
Fixes#26363
Change-Id: Ic5c060522459cd5ce077675d47c848b22ddc34fa
GitHub-Last-Rev: adfb061363
GitHub-Pull-Request: golang/go#26383
Reviewed-on: https://go-review.googlesource.com/123956
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously fmt would first obtain a list of map keys
and then look up the value for each key. Since NaNs can
be map keys but cannot be fetched directly, the lookup would
fail and return a zero reflect.Value, which formats as <nil>.
golang.org/cl/33572 added a map iterator to the reflect package
that is used in this CL to retrieve the key and value from
the map and prints the correct value even for keys that are not
equal to themselves.
Fixes#14427
Change-Id: I9e1522959760b3de8b7ecf7a6e67cd603339632a
Reviewed-on: https://go-review.googlesource.com/129777
Reviewed-by: Alan Donovan <adonovan@google.com>
Fix the wording in "strconv" and "fmt" to make explicit
that the "g" and "G" formats remove trailing zeroes.
Fixes#25082
Change-Id: I2e2ad0a98d2ea27a3a8a006a0563b366f7a3b71b
Reviewed-on: https://go-review.googlesource.com/127135
Reviewed-by: Rob Pike <r@golang.org>
The documentation for %v behavior for compound objects uses an ellipsis
to indicate indefinite lenght of elements. This is done for struct
fields as well as elements of arrays and slices. This adds the missing
ellipsis for maps.
Change-Id: Ia433387fe189d2daf5095df32085a541458f00a1
Reviewed-on: https://go-review.googlesource.com/107623
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the Scan functions documentation, clarify that for float/complex
literals in scientific notation both decimal (e) and binary (p)
exponents are accepted.
Fixes#24453
Change-Id: Ic6dcdb0c36e088ffb65177038aff7a57ab56b805
Reviewed-on: https://go-review.googlesource.com/107416
Reviewed-by: Rob Pike <r@golang.org>
Hide in the source code instead of in the separate whitelist.
Removes the only printf false positive in the standard library.
Change-Id: I99285e67588c7c93bd56d59ee768a03be7c301e7
Reviewed-on: https://go-review.googlesource.com/74590
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The complainant is confused by the ambiguity of 'next' in the
phrase 'next operand'. It seems clear enough to me that things
are always read left to right when formatting, but to calm the
waters we add a clarifying parenthetical.
Fixes#22275
Change-Id: I82418c1e987db736f4bee0faa53fe715c9cde8f5
Reviewed-on: https://go-review.googlesource.com/71010
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
