GitLab

Fixes #18772

Change-Id: Ib5d9ffa0abd35b9d3ca83bac139aece0f3c9702d
Reviewed-on: https://go-review.googlesource.com/37313

Reviewed-by: Rob Pike <r@golang.org>

Added an alternate form of printing floats and complex values
by specifying the sharp flag.

Output formatted using the the verbs v, e, E, f, F, g and G in
combination with the sharp flag will always include a decimal point.

The alternate form specified by the sharp flag for %g and %G verbs
will not truncate trailing zeros and assume a default precision of 6.

Fixes #18857.

Change-Id: I4d776239e06d7a6a90f2d8556240a359888cb7c3
Reviewed-on: https://go-review.googlesource.com/37051

Reviewed-by: Rob Pike <r@golang.org>

Fixes #17409.

Change-Id: Ib49ff4a467431b5c1e6637e5144979cf0bfba489
Reviewed-on: https://go-review.googlesource.com/31817

Reviewed-by: Martin Möhrmann <martisch@uos.de>
Reviewed-by: Quentin Smith <quentin@golang.org>

It's the same as %#x not %x.

Just a documentation change; tests already cover it.

Fixes #17322

Change-Id: Ia9db229f781f9042ac5c0bb824e3d7a26fb74ec5
Reviewed-on: https://go-review.googlesource.com/31254

Reviewed-by: Russ Cox <rsc@golang.org>

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>

It is better to document what golang does, rather than how it differs
from languages which readers may or may not know.

That the output format is based on the type is basically self-evident
if you consider this just in go terms.

Change-Id: I0223e9b4cb67cc83a9ebe4d424e6c151d7ed600f
Reviewed-on: https://go-review.googlesource.com/28393

Reviewed-by: Rob Pike <r@golang.org>

Change-Id: Iae4855c52c4da9755277251d22121226507ea26a
Reviewed-on: https://go-review.googlesource.com/23074

Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #15339

Change-Id: I0b006deefb58ccfc47beae4e1b8da3d77fafda6b
Reviewed-on: https://go-review.googlesource.com/22148

Reviewed-by: Rob Pike <r@golang.org>

Documentation change only.

Fixes #15178.

Change-Id: I3c7d80ce9e668ac7515f7ebb9da80f3bd8e534d6
Reviewed-on: https://go-review.googlesource.com/22006

Reviewed-by: Ian Lance Taylor <iant@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>

Fixes #12340.

Change-Id: I17a8b3711a8593ec60882a0dcadb38f0cc138f4b
Reviewed-on: https://go-review.googlesource.com/13949

Reviewed-by: Rob Pike <r@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>

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>

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>

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>

Fixes #9632.

Change-Id: Ic4d7cad8ff62023c1beecd2d62e48eb9258f5306
Reviewed-on: https://go-review.googlesource.com/3013

Reviewed-by: Rob Pike <r@golang.org>

Change-Id: I7b65cf3b67bef8950115066d6d12b25cd0a5edfc
Reviewed-on: https://go-review.googlesource.com/2272

Reviewed-by: Rob Pike <r@golang.org>

Stupid mistake in previous CL.

TBR=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/166880043

It now echoes what strconv.FormatFloat says.

Fixes #9012.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/169730043

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

Previous behavior was undocumented and inconsistent. Now it is documented
and consistent and measures the input size, since that makes more sense
when talking about %q and %x. For %s the change has no effect.

Fixes #8151.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/144540044

Fixes #8241.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/144420043

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.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/110110045

LGTM=ruiu, bradfitz
R=golang-codereviews, bradfitz, ruiu
CC=golang-codereviews
https://golang.org/cl/91840044

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/86600045

Their priority was not documented.

Fixes #7571.

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/80360043

Rationale:
        It already is for scanning.
        It is accepted for complexes already, but doesn't work.
        It's analogous to %G and %E.
        C accepts it too, and we try to be roughly compatible.
Fixes #7518.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/77580044

%q quotes each element of a string slice; this was never explained in the docs.
Fixes #7015.

LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews
https://golang.org/cl/77140044

Fixes #7048.

LGTM=dominik.honnef
R=golang-codereviews, dominik.honnef
CC=golang-codereviews
https://golang.org/cl/74280044

Fixes #5730.

R=dsymonds, r, kamil.kisiel
CC=golang-dev
https://golang.org/cl/11998044

When scanning input and "white space" is permitted, a carriage return
followed immediately by a newline (\r\n) is treated exactly the same
as a plain newline (\n). I hope this makes it work better on Windows.

We do it everywhere, not just on Windows, since why not?

Fixes #5391.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12142043

Fixes #5730.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12141043

The old code put the index before the period in the precision;
it should be after so it's always before the star, as documented.
A little trickier to do in one pass but compensated for by more
tests and catching a couple of other error cases.

R=rsc
CC=golang-dev
https://golang.org/cl/9751044

This text is added to doc.go:

        Explicit argument indexes:

        In Printf, Sprintf, and Fprintf, the default behavior is for each
        formatting verb to format successive arguments passed in the call.
        However, the notation [n] immediately before the verb indicates that the
        nth one-indexed argument is to be formatted instead. The same notation
        before a '*' for a width or precision selects the argument index holding
        the value. After processing a bracketed expression [n], arguments n+1,
        n+2, etc. will be processed unless otherwise directed.

        For example,
                fmt.Sprintf("%[2]d %[1]d\n", 11, 22)
        will yield "22, 11", while
                fmt.Sprintf("%[3]*[2].*[1]f", 12.0, 2, 6),
        equivalent to
                fmt.Sprintf("%6.2f", 12.0),
        will yield " 12.00". Because an explicit index affects subsequent verbs,
        this notation can be used to print the same values multiple times
        by resetting the index for the first argument to be repeated:
                fmt.Sprintf("%d %d %#[1]x %#x", 16, 17)
        will yield "16 17 0x10 0x11".

The notation chosen differs from that in C, but I believe it's easier to read
and to remember (we're indexing the arguments), and compatibility with
C's printf was never a strong goal anyway.

While we're here, change the word "field" to "arg" or "argument" in the
code; it was being misused and was confusing.

R=rsc, bradfitz, rogpeppe, minux.ma, peter.armitage
CC=golang-dev
https://golang.org/cl/9680043

Fixes #5350.

R=r, minux.ma
CC=golang-dev
https://golang.org/cl/8950043

Fixes #4858.

R=golang-dev, bradfitz, r, rsc
CC=golang-dev
https://golang.org/cl/7387044

Fixes #4581.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7000052

Remove trailing whitespace in comments.
No other changes.

R=r
CC=golang-dev
https://golang.org/cl/6815053