| Age | Commit message (Collapse) | Author |
|---|
|
This will let low-level things depend on the canonical routines,
even for floating-point printing.
Change-Id: I31207dc6584ad90d4e365dbe6eaf20f8662ed22d
Reviewed-on: https://go-review.googlesource.com/c/go/+/716000
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Both Eisel-Lemire and Ryu depend on a table of
truncated 128-bit mantissas of powers of 10,
and so will Dragonbox.
This CL:
- Moves the table to a separate file, so it doesn't look tied to Eisel-Lemire.
- Introduces a uint128 type in math.go for the table values,
since .Hi and .Lo are clearer than [1] and [0].
- Generates the table from a standalone generator pow10gen.go.
- Adds a new pow10 function in math.go to handle table access details.
- Factors a 64x128->192-bit multiply into umul192 in math.go.
- Moves multiplication by log₁₀ 2 and log₂ 10 into math.go.
- Introduces an import_test.go to avoid having to type differently
cased names in test code versus regular code.
- Introduces named constants for the floating-point size parameters.
Previously these were only in the floatInfo global variables.
- Changes the BenchmarkAppendUintVarlen subtest names
to be more useful.
Change-Id: I9826ee5f41c5c19be3b6a7c3c5f277ec6c23b39a
Reviewed-on: https://go-review.googlesource.com/c/go/+/712661
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Follow the approach used in strconv's readFloat, decimal.set, and Atoi,
where leading '+' and '-' are handled using a switch for clarity and
consistency.
Change-Id: I41eff34ce90b5ac43fcdbc0bb88910d6d5fb4d39
GitHub-Last-Rev: 0c9d2efb5a828515fa00afdba8c436aa31fb0e53
GitHub-Pull-Request: golang/go#73185
Reviewed-on: https://go-review.googlesource.com/c/go/+/663257
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
To make code a bit simpler.
Change-Id: I33b3e04bc810a4838584c477854ef612b355579a
GitHub-Last-Rev: 6d5bbc2a2877193e1319b9e626f408eda399666e
GitHub-Pull-Request: golang/go#71927
Reviewed-on: https://go-review.googlesource.com/c/go/+/651975
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
|
|
strings for 'NaN' -> string for 'NaN'
Change-Id: Ia415644a1b651e6ef9996ad24dd9708a60e57dfc
GitHub-Last-Rev: 877f1c3eb1dc885915ae75385c5d38ee6f5fd9b1
GitHub-Pull-Request: golang/go#53246
Reviewed-on: https://go-review.googlesource.com/c/go/+/410494
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
The documentation for strconv.ParseFloat mentions that it "accepts
decimal and hexadecimal floating-point number syntax", but it doesn't
specify what those formats entail. For example, "0x10" is not allowed;
you need an explicit exponent, as in "0x10p0".
This clarifies that ParseFloat accepts the Go syntax for floating-point
literals, and links to that spec section. I've also linked to the
relevant spec section for ParseInt's doc comment, which already said
"as defined by the Go syntax for integer literals".
Change-Id: Ib5d2b408bdd01ea0b9f69381a9dbe858f6d1d424
Reviewed-on: https://go-review.googlesource.com/c/go/+/410335
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Run the updated gofmt, which reformats doc comments,
on the main repository. Vendored files are excluded.
For #51082.
Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407
Reviewed-on: https://go-review.googlesource.com/c/go/+/384268
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Previously we would sometimes return ErrRange if the parseable part of
the floating point number was out of range.
Fixes #46628
Change-Id: I15bbbb1e2a56fa27c19fe25ab5554d988cbfd9d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/325750
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This is a partial revert of https://go-review.googlesource.com/c/go/+/248219
because we found that a non-trivial amount of code erroneously calls
ParseFloat(s, 10) or even ParseFloat(s, 0) and expects it to work --
before that change was merged, ParseFloat accepted a bitSize of
anything other than 32 or 64 to mean 64 (and ParseComplex was similar).
So revert that behavior to avoid breaking people's code, and add tests
for this.
I may add a vet check to flag ParseFloat(s, not_32_or_64) in a later
change.
See #42297 for more details.
Change-Id: I4bc0156bd74f67a39d5561b6e5fde3f2d20bd622
Reviewed-on: https://go-review.googlesource.com/c/go/+/267319
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
In ParseComplex, the "size" passed to parseFloatPrefix should be 64 for
complex128, not 128. It still works because of how parseFloatPrefix
is forgiving about the size if it's not 32, but worth fixing anyway.
Make ParseComplex and ParseFloat return a bit size error for anything
other than 128 or 64 (for ParseComplex), or 64 or 32 (for ParseFloat).
Add "InvalidBitSize" tests for these cases.
Add tests for ParseComplex with bitSize==64: this is done in a similar
way to how the ParseFloat 32-bit tests work, re-using the tests for the
larger bit size.
Add tests for FormatComplex -- there were none before.
Fixes #40706
Change-Id: I16ddd546e5237207cc3b8c2181dd708eca42b04f
Reviewed-on: https://go-review.googlesource.com/c/go/+/248219
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Minux Ma <minux@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
In many cases, it is not necessary to parse long
decimal mantissas entirely to produce the correctly
rounded floating-point number. It is enough to parse
the short, rounded lower and upper bounds and in most cases
they round to the same floating point number because uint64
can hold 19 digits.
Previously this case was handled by the extFloat code path
(Grisu3 algorithm).
name old time/op new time/op delta
Atof64Big-4 1.07µs ± 2% 0.11µs ± 2% -89.61% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 8.03µs ± 2% 0.14µs ± 7% -98.24% (p=0.000 n=10+10)
Atof32RandomLong-4 760ns ± 1% 156ns ± 0% -79.46% (p=0.000 n=10+8)
Benchmarks versus extFloat:
name old time/op new time/op delta
Atof64Big-4 121ns ± 3% 111ns ± 2% -7.93% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 144ns ± 1% 142ns ± 7% ~ (p=0.167 n=10+10)
Atof32RandomLong-4 129ns ± 1% 156ns ± 0% +21.12% (p=0.000 n=10+8)
Change-Id: Id734b8c11e74b49a444fda67ee72870ae9422e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/264677
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Prior to this commit, strconv.ParseFloat (known in C as atof) takes the
first of four algorithms to succeed: atof64exact, eiselLemire64,
extFloat, fallback. The Eisel-Lemire implementation is a recent addition
but, now that it exists, the extFloat implementation (based on the
algorithm used by https://github.com/google/double-conversion) is
largely redundant. This Go program:
func parseOneMillionFloats(bitSize int, normallyDistributed bool) {
rng := rand.New(rand.NewSource(1))
for i := 0; i < 1_000_000; {
x := 0.0
if normallyDistributed {
x = rng.NormFloat64()
} else if bitSize == 32 {
x = float64(math.Float32frombits(rng.Uint32()))
} else {
x = math.Float64frombits(
uint64(rng.Uint32())<<32 | uint64(rng.Uint32()))
}
if math.IsInf(x, 0) {
continue
}
s := strconv.FormatFloat(x, 'g', -1, bitSize)
strconv.ParseFloat(s, bitSize)
i++
}
}
triggers the four algorithms by these percentages:
bitSize=32, normallyDistributed=false
07.4274% atof32exact
91.2982% eiselLemire32
00.8673% extFloat
00.0269% fallback
bitSize=32, normallyDistributed=true
27.6356% atof32exact
72.3641% eiselLemire32
00.0003% extFloat
00.0000% fallback
bitSize=64, normallyDistributed=false
01.2076% atof64exact
98.6216% eiselLemire64
00.1081% extFloat
00.0130% fallback
bitSize=64, normallyDistributed=true
24.8826% atof64exact
75.1174% eiselLemire64
00.0000% extFloat
00.0000% fallback
This commit removes the extfloat.go atof code (but keeps the extfloat.go
ftoa code for now), reducing the number of atof algorithms from 4 to 3.
The benchmarks (below) show some regressions but these are arguably
largely artificial situations.
Atof*RandomBits generates uniformly distributed uint32/uint64 values and
reinterprets the bits as float32/float64 values. The change in headline
numbers (arithmetic means) are primarily due to relatively large changes
for relatively rare cases.
Atof64Big parses a hard-coded "123456789123456789123456789".
name old time/op new time/op delta
Atof64Decimal-4 47.1ns ± 1% 47.4ns ± 2% ~ (p=0.516 n=5+5)
Atof64Float-4 56.4ns ± 1% 55.9ns ± 2% ~ (p=0.206 n=5+5)
Atof64FloatExp-4 68.8ns ± 0% 68.7ns ± 1% ~ (p=0.516 n=5+5)
Atof64Big-4 157ns ± 2% 1528ns ± 2% +875.99% (p=0.008 n=5+5)
Atof64RandomBits-4 156ns ± 1% 186ns ± 1% +19.49% (p=0.008 n=5+5)
Atof64RandomFloats-4 144ns ± 0% 143ns ± 1% ~ (p=0.365 n=5+5)
Atof32Decimal-4 47.6ns ± 1% 47.5ns ± 2% ~ (p=0.714 n=5+5)
Atof32Float-4 54.3ns ± 2% 54.1ns ± 1% ~ (p=0.532 n=5+5)
Atof32FloatExp-4 75.2ns ± 1% 75.7ns ± 3% ~ (p=0.794 n=5+5)
Atof32Random-4 108ns ± 1% 120ns ± 1% +10.54% (p=0.008 n=5+5)
Fixes #36657
Change-Id: Id3c4e1700f969f885b580be54c8892b4fe042a79
Reviewed-on: https://go-review.googlesource.com/c/go/+/264518
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
|
|
This does for ParseFloat(etc, 32) what commit a2eb53c571 did for
ParseFloat(etc, 64).
name old time/op new time/op delta
Atof32Decimal-4 48.3ns ± 4% 48.8ns ± 2% ~ (p=0.548 n=5+5)
Atof32Float-4 56.2ns ± 5% 54.7ns ± 3% ~ (p=0.246 n=5+5)
Atof32FloatExp-4 104ns ± 0% 76ns ± 2% -27.19% (p=0.008 n=5+5)
Atof32Random-4 142ns ± 2% 109ns ± 1% -23.07% (p=0.008 n=5+5)
Change-Id: I6ee5a2f2d791d4fe3028f1d40aca96400120fda0
Reviewed-on: https://go-review.googlesource.com/c/go/+/264517
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Also fix BenchmarkAtof64Random* to initialize the test data when none
of the TestAtof* tests are run.
Passing "go test -test.count=5 -test.run=xxx -test.bench=Atof64" on to
benchstat:
name old time/op new time/op delta
Atof64Decimal-4 47.9ns ± 0% 48.3ns ± 1% ~ (p=0.238 n=4+5)
Atof64Float-4 58.3ns ± 3% 57.7ns ± 0% ~ (p=0.151 n=5+5)
Atof64FloatExp-4 107ns ± 0% 71ns ± 1% -33.89% (p=0.016 n=4+5)
Atof64Big-4 163ns ± 0% 166ns ± 2% ~ (p=0.159 n=4+5)
Atof64RandomBits-4 299ns ± 1% 166ns ± 1% -44.41% (p=0.008 n=5+5)
Atof64RandomFloats-4 188ns ± 1% 144ns ± 0% -23.03% (p=0.008 n=5+5)
The canada.json file from github.com/miloyip/nativejson-benchmark is
full of geospatial coordinates (i.e. numbers). With this program:
src, _ := ioutil.ReadFile("canada.json")
for i := 0; i < 5; i++ {
now := time.Now()
for j := 0; j < 10; j++ {
dst := interface{}(nil)
if err := json.Unmarshal(src, &dst); err != nil {
log.Fatal(err)
}
}
fmt.Println(time.Since(now))
}
Median of the 5 printed numbers, lower is better.
Before: 760.819549ms
After: 702.651646ms
Ratio: 1.08x
The new detailedPowersOfTen table weighs in at 596 * 16 = 9536 bytes,
but some of that weight gain can be clawed back, in a follow-up commit,
that folds in the existing powersOfTen table in extfloat.go.
RELNOTE=yes
Change-Id: I3953110deaa1f5f6941e88e8417c4665b649ed80
Reviewed-on: https://go-review.googlesource.com/c/go/+/260858
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
|
|
The recently added function parseFloatPrefix tested the entire
string for correct placement of separators rather than just the
consumed part. The 4-char fix is in readFloat (atof.go:303).
Added more tests. Also added some white space for nicer
grouping of the test cases.
While at it, removed the need for calling testing.Run.
Fixes #38962.
Change-Id: Ifce84f362bb4ede559103f8d535556d3de9325f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/233017
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Adds two functions to deal with complex numbers:
* FormatComplex
* ParseComplex
ParseComplex accepts complex numbers in this format: N+Ni
Fixes #36771
Change-Id: Id184dc9e277e5fa01a714ad656a88255ead05085
GitHub-Last-Rev: 036a075d36363774a95f6000b7c4098896474744
GitHub-Pull-Request: golang/go#36815
Reviewed-on: https://go-review.googlesource.com/c/go/+/216617
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
parseFloatPrefix accepts a string if it has a valid floating-point
number as prefix. Make sure that "infi", "infin", ... etc. are
accepted as valid numbers "inf" with suffix "i", "in", etc. This
is important for parsing complex numbers such as "0+infi".
This change does not affect the correctness of ParseFloat because
ParseFloat rejects strings that contain a suffix after a valid
floating-point number.
Updates #36771.
Change-Id: Ie1693a8ca2f8edf07b57688e0b35751b7100d39d
Reviewed-on: https://go-review.googlesource.com/c/go/+/231237
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
parseFloatPrefix will make it easier to implement ParseComplex.
Verified that there's no relevant performance impact:
Benchmarks run on a "quiet" MacBook Pro, 3.3GHz Dual-Core Intel Core i7,
with 16GB 2133MHz LPDDR3 RAM running macOS 10.15.4.
name old time/op new time/op delta
Atof64Decimal-4 38.2ns ± 4% 38.4ns ± 3% ~ (p=0.802 n=5+5)
Atof64Float-4 41.1ns ± 3% 43.0ns ± 1% +4.77% (p=0.008 n=5+5)
Atof64FloatExp-4 71.9ns ± 3% 70.1ns ± 1% ~ (p=0.063 n=5+5)
Atof64Big-4 124ns ± 5% 119ns ± 0% ~ (p=0.143 n=5+4)
Atof64RandomBits-4 57.2ns ± 1% 55.7ns ± 2% -2.66% (p=0.016 n=4+5)
Atof64RandomFloats-4 56.8ns ± 1% 56.9ns ± 4% ~ (p=0.556 n=4+5)
Atof32Decimal-4 35.4ns ± 5% 35.9ns ± 0% ~ (p=0.127 n=5+5)
Atof32Float-4 39.6ns ± 7% 40.3ns ± 1% ~ (p=0.135 n=5+5)
Atof32FloatExp-4 73.7ns ± 7% 71.9ns ± 0% ~ (p=0.175 n=5+4)
Atof32Random-4 103ns ± 6% 98ns ± 2% -5.03% (p=0.008 n=5+5)
Updates #36771.
Change-Id: I8ff66b582ae8b468d89c9ffc35c569c735cf0341
Reviewed-on: https://go-review.googlesource.com/c/go/+/230737
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Run underscore validation only if we have seen underscores.
Some performance results on my laptop:
name old time/op new time/op delta
Atof64Decimal-12 30.5ns ± 0% 23.8ns ± 0% -22.02% (p=0.016 n=5+4)
Atof64Float-12 39.0ns ± 0% 28.7ns ± 0% -26.39% (p=0.002 n=6+6)
Atof64FloatExp-12 64.4ns ± 1% 54.4ns ± 1% -15.65% (p=0.002 n=6+6)
Atof64Big-12 115ns ± 1% 87ns ± 1% -24.45% (p=0.002 n=6+6)
Atof64RandomBits-12 187ns ±14% 156ns ±19% -16.46% (p=0.032 n=6+6)
Atof64RandomFloats-12 126ns ± 0% 105ns ± 1% -16.65% (p=0.000 n=6+5)
Atof32Decimal-12 32.0ns ± 1% 24.0ns ± 1% -24.97% (p=0.002 n=6+6)
Atof32Float-12 37.1ns ± 1% 27.0ns ± 1% -27.42% (p=0.002 n=6+6)
Atof32FloatExp-12 68.4ns ± 1% 54.2ns ± 1% -20.77% (p=0.002 n=6+6)
Atof32Random-12 92.0ns ± 1% 77.4ns ± 0% -15.81% (p=0.000 n=6+5)
ParseInt/Pos/7bit-12 19.4ns ± 1% 13.8ns ±10% -28.94% (p=0.002 n=6+6)
ParseInt/Pos/26bit-12 29.1ns ± 1% 19.8ns ± 2% -31.92% (p=0.002 n=6+6)
ParseInt/Pos/31bit-12 33.1ns ± 0% 22.3ns ± 3% -32.62% (p=0.004 n=5+6)
ParseInt/Pos/56bit-12 47.8ns ± 1% 30.7ns ± 1% -35.78% (p=0.004 n=6+5)
ParseInt/Pos/63bit-12 51.9ns ± 1% 33.4ns ± 2% -35.49% (p=0.002 n=6+6)
ParseInt/Neg/7bit-12 18.5ns ± 4% 13.4ns ± 3% -27.88% (p=0.002 n=6+6)
ParseInt/Neg/26bit-12 28.4ns ± 3% 19.7ns ± 3% -30.38% (p=0.002 n=6+6)
ParseInt/Neg/31bit-12 31.9ns ± 1% 21.8ns ± 2% -31.56% (p=0.002 n=6+6)
ParseInt/Neg/56bit-12 46.2ns ± 0% 30.6ns ± 1% -33.73% (p=0.004 n=5+6)
ParseInt/Neg/63bit-12 50.2ns ± 1% 33.2ns ± 1% -33.96% (p=0.002 n=6+6)
Fixes #33330
Change-Id: I119da66457c2fbaf6e88bb90cf56417a16df8f0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/187957
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Fixes #33750.
Updates #31197.
Change-Id: I26f63cef57e5f0eec85b84554c82f6d47b4f41a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/191078
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
In addition to the example that was added in 203b80ab, mention these
special cases in the doc comment. This change also adjusts the example
to include "+Inf", as it was not otherwise mentioned that the plus
symbol may be present.
Fix #30990
Change-Id: I97d66f4aff6a17a6ccc0ee2e7f32e39ae91ae454
Reviewed-on: https://go-review.googlesource.com/c/go/+/179738
Reviewed-by: Alex Miasoedov <msoedov@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This CL modifies ParseInt, ParseUint, and ParseFloat
to accept digit-separating underscores in their arguments.
For ParseInt and ParseUint, the underscores are only
allowed when base == 0.
See golang.org/design/19308-number-literals for background.
For #28493.
Change-Id: I057ca2539d89314643f591ba8144c3ea7126651c
Reviewed-on: https://go-review.googlesource.com/c/160243
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This CL updates ParseFloat to recognize
standard hexadecimal floating-point constants.
See golang.org/design/19308-number-literals for background.
For #29008.
Change-Id: I45f3b0c36b5d92c0e8a4b35c05443a83d7a6d4b3
Reviewed-on: https://go-review.googlesource.com/c/160241
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Fixes #15364.
Change-Id: Id2a349896064c7c9e00e36c55162068bf18162b2
Reviewed-on: https://go-review.googlesource.com/22272
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
|
|
Change-Id: I69a2b6a99a53c875162be8a7d86455559cd74504
Reviewed-on: https://go-review.googlesource.com/11371
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
|
