This change accepts the 'i' suffix on binary and octal integer
literals as well as hexadecimal floats. The suffix was already
accepted on decimal integers and floats.

See also the respective language in the spec change:
https://golang.org/cl/161098

Change-Id: I0c182bdf58f8fd1f70090e581b3ccb2f5e2e4e79
Reviewed-on: https://go-review.googlesource.com/c/162880Reviewed-by: Ian Lance Taylor <iant@golang.org>

There are several places where a new (internal) complex constant is allocated
via new(Mpcplx) rather than newMpcmplx(). The problem with using new() is that
the Mpcplx data structure's Real and Imag components don't get initialized with
an Mpflt of the correct precision (they have precision 0, which may be adjusted
later).

In all cases but one, the components of those complex constants are set using
a Set operation which "inherits" the correct precision from the value that is
being set.

But when creating a complex value for an imaginary literal, the imaginary
component is set via SetString which assumes 64bits of precision by default.
As a result, the internal representation of 0.01i and complex(0, 0.01) was
not correct.

Replaced all used of new(Mpcplx) with newMpcmplx() and added a new test.

Fixes #30243.

Change-Id: Ife7fd6ccd42bf887a55c6ce91727754657e6cb2d
Reviewed-on: https://go-review.googlesource.com/c/163000
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Updates #28387

Change-Id: Ie5a5f1f798eb5900f9c7bdef165abcca02dd0dde
Reviewed-on: https://go-review.googlesource.com/c/163037
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates #30228

Change-Id: I3c7864e6725312df5ec978cdc130ccfe8fc2e738
Reviewed-on: https://go-review.googlesource.com/c/162836
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates #30228

Change-Id: I6a38269f322d906702921b3879ff48c8a96ab511
Reviewed-on: https://go-review.googlesource.com/c/162831
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This applies the new gofmt literal normalizations to the library.

Change-Id: I8c1e8ef62eb556fc568872c9f77a31ef236348e7
Reviewed-on: https://go-review.googlesource.com/c/162539
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

An 'i' suffix on an integer literal marks the integer literal as
a decimal integer imaginary value, even if the literal without the
suffix starts with a 0 and thus looks like an octal value:

	0123i == 123i // != 0123 * 1i

This is at best confusing, and at worst a potential source of bugs.
It is always safe to rewrite such literals into the equivalent
literal without the leading 0.

This CL implements this normalization.

Change-Id: Ib77ad535f98b5be912ecbdec20ca1b472c1b4973
Reviewed-on: https://go-review.googlesource.com/c/162538
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

We will soon switch GO111MODULE to 'on' by default, and when that
happens these tests will otherwise break.

Updates #30228

Change-Id: I1016d429b1dfb889d1aae8bc86fb2567cf0fc56f
Reviewed-on: https://go-review.googlesource.com/c/162697
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

In module mode, building the current directory requires a go.mod file
(in order to determine the import path of the package).

Change the tests to pass explicit file arguments instead, since those
can be built in module mode without defining a module.

Updates #30228

Change-Id: I680c658d1f79645f73ad4d1e88189ea50a4852e9
Reviewed-on: https://go-review.googlesource.com/c/162837
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

Updates #19113.

Change-Id: I4726f51c5061c33979cdd061f6d4616fa97edb9a
Reviewed-on: https://go-review.googlesource.com/c/161201Reviewed-by: Rob Pike <r@golang.org>

This test was excluded from the go/types std lib test
because it tested old behavior (shift count must be
an unsigned int). With the compiler changes made and
the test adjusted accordingly, we can include it again.

Updates #19113.

Change-Id: If9b6b83505d2bd2b426fcefa225986d73658a229
Reviewed-on: https://go-review.googlesource.com/c/159319Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

CL 154057 adds guards agaist out-of-bound reads from readonly
constants. It turns out that in dead code, the offset can also
be negative. Guard against negative offset as well.

Fixes #30257.

Change-Id: I47c2a2e434dd466c08ae6f50f213999a358c796e
Reviewed-on: https://go-review.googlesource.com/c/162819Reviewed-by: Keith Randall <khr@golang.org>

Updates #27302
Updates #22907

Change-Id: Iac6957f3517265dfb9c662efb7af31192e3bfd6c
Reviewed-on: https://go-review.googlesource.com/c/162960Reviewed-by: Ian Lance Taylor <iant@golang.org>

Allow shifts by signed amounts. Panic if the shift amount is negative.

TODO: We end up doing two compares per shift, see Ian's comment
https://github.com/golang/go/issues/19113#issuecomment-443241799 that
we could do it with a single comparison in the normal case.

The prove pass mostly handles this code well. For instance, it removes the
<0 check for cases like this:
    if s >= 0 { _ = x << s }
    _ = x << len(a)

This case isn't handled well yet:
    _ = x << (y & 0xf)
I'll do followon CLs for unhandled cases as needed.

Update #19113

R=go1.13

Change-Id: I839a5933d94b54ab04deb9dd5149f32c51c90fa1
Reviewed-on: https://go-review.googlesource.com/c/158719
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Fixes #30263

Change-Id: Iefb3d8baf815c19eaf915a59048e1da799ca0cdf
Reviewed-on: https://go-review.googlesource.com/c/162957
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #30258

Change-Id: I73b63eb9d3aca00f562fdc3af010e96269bb6b9c
Reviewed-on: https://go-review.googlesource.com/c/162891
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>

In the general case, we do not know the correct module path for a new
module unless we have checked its VCS tags for a major version. If we
do not know the correct path, then we should not synthesize a go.mod
file automatically from it.

On the other hand, we don't want to run VCS commands in the working
directory without an explicit request by the user to do so: 'go mod
init' can reasonably invoke a VCS command, but 'go build' should not.

Therefore, we should only create a go.mod file during 'go mod init'.

This change removes the previous behavior of synthesizing a file
automatically, and instead suggests a command that the user can opt to
run explicitly.

Updates #29433
Updates #27009
Updates #30228

Change-Id: I8c4554969db17156e97428df220b129a4d361040
Reviewed-on: https://go-review.googlesource.com/c/162699
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

Change-Id: I6e7035db4b3e2a09e5655eb7646eea9d99fb7118
Reviewed-on: https://go-review.googlesource.com/c/162917Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates #30029

Change-Id: I88e09035d675e7a6855ada0262eb42636c9822cc
Reviewed-on: https://go-review.googlesource.com/c/162417Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: I6801676335924414ce50249df2b7bea08886b203
Reviewed-on: https://go-review.googlesource.com/c/162360Reviewed-by: Filippo Valsorda <filippo@golang.org>

TestDumpRequest was failing with -count=2 or more
because for test cases that involved mustReadRequest,
the body was created as a *bufio.Reader. DumpRequest
and DumpRequestOut would then read the body until EOF
and would close it after use.
However, on re-runs of the test, the body would
be terminally exhausted and result in an unexpected
error "http: invalid Read on closed Body".

The update to the test cases adds an extra field "GetReq"
which allows us to construct requests per run of the tests
and hence make the test indefinitely re-runnable/idempotent.
"Req" or "GetReq" are mutually exclusive: either one of them
can be set or nil, but not both.

Fixes #26858

Change-Id: Ice3083dac1aa3249da4afc7075cd984eb159530d
Reviewed-on: https://go-review.googlesource.com/c/153377
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In runtime.gopanic, the _panic object p is stack allocated and
referenced from gp._panic. With stack objects, p on stack is dead
at the point preprintpanics runs. gp._panic points to p, but
stack scan doesn't look at gp. Heap scan of gp does look at
gp._panic, but it stops and ignores the pointer as it points to
the stack. So whatever p points to may be collected and clobbered.
We need to scan gp._panic explicitly during stack scan.

To test it reliably, we introduce a GODEBUG mode "clobberfree",
which clobbers the memory content when the GC frees an object.

Fixes #30150.

Change-Id: I11128298f03a89f817faa221421a9d332b41dced
Reviewed-on: https://go-review.googlesource.com/c/161778
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Fixes #30199

Change-Id: Ib4586e3facb8c0985c8882482d94843b648b9d2f
Reviewed-on: https://go-review.googlesource.com/c/162257
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I46fa43f6c5ac49386f4622e1363d8976f49c0894
Reviewed-on: https://go-review.googlesource.com/c/162019Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #30197

Change-Id: I08b592fbd477d6879eb5d3b7fcbbc8322ea90103
Reviewed-on: https://go-review.googlesource.com/c/162078
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This CL modifies ParseInt and ParseUint to recognize
0b and 0o as binary and octal base prefixes when base == 0.

See golang.org/design/19308-number-literals for background.

For #19308.
For #12711.

Change-Id: I8efe067f415aa517bdefbff7e230d3fa1694d530
Reviewed-on: https://go-review.googlesource.com/c/160244
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@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 FormatFloat to format
standard hexadecimal floating-point constants,
using the 'x' and 'X' verbs.

See golang.org/design/19308-number-literals for background.

For #29008.

Change-Id: I540b8f71d492cfdb7c58af533d357a564591f28b
Reviewed-on: https://go-review.googlesource.com/c/160242
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>

Change-Id: I15279e4aa9306bde925929907a7b5e7ef5d8b642
GitHub-Last-Rev: 6bc2d66aecd424b322ec0c23b280e74cb22e08c3
GitHub-Pull-Request: golang/go#30193
Reviewed-on: https://go-review.googlesource.com/c/162018Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ia546d3f0a12a3c3c291f7b6d5291193fdd47d7dd
Reviewed-on: https://go-review.googlesource.com/c/161966
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Permit shifts by non-constant signed integer shift counts.
Share logic for constant shift counts in non-constant
shifts and improve error messages a little bit.

R=Go1.13

Updates #19113.

Change-Id: Ia01d83ca8aa60a6a3f4c49f026e0c46396f852be
Reviewed-on: https://go-review.googlesource.com/c/159317
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

This CL introduces text/scanner support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.
The new code is closely mirroring the respective code for number literals in
cmd/compile/internal/syntax/scanner.go.

Uniformly use the term "invalid" rather than "illegal" in error messages
to match the respective error messages in the other scanners directly.

R=Go1.13

Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.

Change-Id: I2f291de13ba5afc0e530cd8326e6bf4c3858ebac
Reviewed-on: https://go-review.googlesource.com/c/161199
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The -asmhdr flag is used to generate header files for assembly code
such that that code has access to compile-time constants. During
the build these constants end up in the (ephemeral) file go_asm.h.

For historical reasons, floating-point and complex constants are
printed with a 'p' exponent but with decimal mantissa; also, because
of the compiler-internal precision of 512 bits, the mantissae are quite
large (and conversions are comparatively slow).

With the changes to the new Go 2 number literals, the respective
upcoming changes to text/scanner (which in turn is used by the assembler)
will make text/scanner newly accept hexadecimal floats; but also decimal
floats using the incorrect 'p' exponent and report an error in that case.

As a consequence, the assembler will report an error when trying to parse
the before-mentioned decimal floating-point values which are using 'p'
exponents. Since these constants are never needed in the assembly code,
do not emit them in the first place.

Change-Id: I06c7c96b04e8d062441120107992472f87a651b2
Reviewed-on: https://go-review.googlesource.com/c/161904
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Make sure Scanner.tokEnd is set before we call Scanner.Error
and update documentation accordingly.
(Until now tokEnd was only set before returning from Scan,
so a call to TokenText during error handling may have crashed.)

While at it, tighten a check in Scanner.TokenText to ensure
Scanner.tokEnd >= Scanner.tokPos if we have a token.

Also, silence error messages to Stderr in unrelated TestIllegalExponent.

Fixes #29723.

Change-Id: Ia97beeae91eaf9e0ed3dada0a806f1f7122461cc
Reviewed-on: https://go-review.googlesource.com/c/157819Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Rewrite non-decimal number prefixes to always use a lower-case base
("0X" -> "0x", etc.), and rewrite exponents to use a lower-case 'e'
or 'p'. Leave hexadecimal digits and 0-octals alone.

Comparing the best time of 3 runs of `time go test -run All` with
the time for a gofmt that doesn't do the rewrite shows no increase
in runtime for this bulk gofmt application (in fact on my machine
I see a small decline, probably due to cache effects).

R=Go1.13

Updates #12711.
Updates #19308.
Updates #29008.

Change-Id: I9c6ebed2ffa0a6a001c59412a73382090955f5a9
Reviewed-on: https://go-review.googlesource.com/c/160184Reviewed-by: Ian Lance Taylor <iant@golang.org>

This CL ensures that go/types can now handle the new
Go 2 number literals. The relevant changes enabling
them in go/types were made in go/constant in the CL
https://golang.org/cl/160239.

R=Go1.13

Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.

Change-Id: I45c1387198fac94769ac59c5301d86b4e1a1ff98
Reviewed-on: https://go-review.googlesource.com/c/160240Reviewed-by: Russ Cox <rsc@golang.org>

This CL introduces go/constant support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.

R=Go1.13

Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.

Change-Id: I7a55f91b8b6373ae6d98ba923b626d33c5552946
Reviewed-on: https://go-review.googlesource.com/c/160239Reviewed-by: Russ Cox <rsc@golang.org>

R=Go1.13

Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.

Change-Id: Icd25aa7f6e18ed671ea6cf2b1b292899daf4b1a5
Reviewed-on: https://go-review.googlesource.com/c/160018Reviewed-by: Russ Cox <rsc@golang.org>

This CL introduces go/scanner support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.
The new code is closely mirroring the respective code for number literals in
cmd/compile/internal/syntax/scanner.go.

R=Go1.13

Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.

Change-Id: I5315c6aaa7cfc41a618296be20e3acd5114d6b3c
Reviewed-on: https://go-review.googlesource.com/c/159997Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>