They can't be used, so we don't need code generated for them. We just
need to report errors in their bodies.
The compiler currently has a bunch of special cases sprinkled about
for "_" functions, because we never generate a linker symbol for them.
Instead, abort compilation earlier so we never reach any of that
special-case code.
Fixes#29870
Change-Id: I3530c9c353deabcf75ce9072c0b740e992349ee5
Reviewed-on: https://go-review.googlesource.com/c/158845
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
var a []int = ...
p := &a[0]
_ = *p
We don't need to nil check on the 3rd line. If the bounds check on the 2nd
line passes, we know p is non-nil.
We rely on the fact that any cap>0 slice has a non-nil pointer as its
pointer to the backing array. This is true for all safely-constructed slices,
and I don't see any reason why someone would violate this rule using unsafe.
R=go1.13
Fixes#30366
Change-Id: I3ed764fcb72cfe1fbf963d8c1a82e24e3b6dead7
Reviewed-on: https://go-review.googlesource.com/c/163740
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The comment about losing the high bits is incorrect. We now use these
nops in places where they really need to be a nop. (Before inline
marks, we used them just before deferreturn calls, so they could
clobber any caller-saved values.)
Change-Id: I433d1ec455aa37dab8fef6eb7d407f3737dbb97f
Reviewed-on: https://go-review.googlesource.com/c/158057
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
As discussed in #29242, this optimization is for a bash-ism.
No one writes Go code like this.
In this repo, it triggers only in test/fixedbugs/bug425.go
and that appears to be accidental.
Fixes#29242
Change-Id: I257e6ecc73f24680f7282c6ab28729de4e8b27af
Reviewed-on: https://go-review.googlesource.com/c/163728
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now that checknil has only a single caller, inline it.
Passes toolstash-check.
Change-Id: I5b13596bef84dd9a3e7f4bff8560903f1e54acfb
Reviewed-on: https://go-review.googlesource.com/c/148829
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When looking for the field specified in a composite literal, check that
the specified name is actually a field and not a method.
Fixes#29855.
Change-Id: Id77666e846f925907b1eec64213b1d25af8a2466
Reviewed-on: https://go-review.googlesource.com/c/158938
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The special case for ODOTPTR to handle zero-width fields is unneeded.
It is an artifact of the old backend, from which time this code dates.
The Node to SSA converter is careful to insert a nil check.
This is tested in test/nilptr2.go, among other places.
Passes toolstash-check.
Change-Id: I6c1d99f7ff5abdae9aa08ee047dc088a3fe8dc3c
Reviewed-on: https://go-review.googlesource.com/c/148828
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
They don't work on Android but will be run if the host has gfortran
installed.
Change-Id: I983c5695a9e963def90e4f8264fb00077a0c5e53
Reviewed-on: https://go-review.googlesource.com/c/163838
Run-TryBot: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Its only use was removed in golang.org/cl/114797, committed in October
2018.
Change-Id: I6560ccfb10d7c763f6470b20c853716779c18cee
Reviewed-on: https://go-review.googlesource.com/c/158897
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
To run the standard library tests on Android, the androidtest.bash
script copies GOROOT to the device. Move that logic to the android
exec wrapper, thereby making androidtest.bash obsolete.
Apart from making Android less special, the sharded builder
infrastructure should now be able to run (emulated) Android builders
and trybots without special treatment.
Updates #23824
Change-Id: I41591fea9a15b38c6dcf84046ea57f1e9165eaa5
Reviewed-on: https://go-review.googlesource.com/c/163619
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The androidtest.bash script encodes the additional steps to build
Go and run tests on Android. In order to add sharded builders and
trybots, Android needs to fit into the usual make.bash + cmd/dist test
pattern.
This change moves building the exec wrapper into cmd/dist bootstrap.
Do the same for iOS while we're here.
Updates #23824
Change-Id: I58a1b0679c3a6c92fdc7fff464b469641f1fee74
Reviewed-on: https://go-review.googlesource.com/c/163618
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I forgot how to pull up the ssa debug options help, so instead of
writing -d=ssa/help, I just wrote -d=ssa/. Much to my amusement, the
compiler just crashed, as shown below. Fix that.
panic: runtime error: index out of range
goroutine 1 [running]:
cmd/compile/internal/ssa.PhaseOption(0x7ffc375d2b70, 0x0, 0xdbff91, 0x5, 0x1, 0x0, 0x0, 0x1, 0x1)
/home/mvdan/tip/src/cmd/compile/internal/ssa/compile.go:327 +0x1876
cmd/compile/internal/gc.Main(0xde7bd8)
/home/mvdan/tip/src/cmd/compile/internal/gc/main.go:411 +0x41d0
main.main()
/home/mvdan/tip/src/cmd/compile/main.go:51 +0xab
Change-Id: Ia2ad394382ddf8f4498b16b5cfb49be0317fc1aa
Reviewed-on: https://go-review.googlesource.com/c/154421
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Add _test.go files in the individal directories to invoke 'go build'
with appropriate arguments.
Move the test driver out of cmd/dist so that it's easier to invoke the
test separately (using 'go test .').
Updates #30228
Updates #28387
Change-Id: Ibc4a024a52c12a274058298b41cc90709f7f56c8
Reviewed-on: https://go-review.googlesource.com/c/163420
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A recent change to fix stacktraces for inlined functions
introduced a regression on ppc64le when compiling position
independent code. That happened because ginsnop2 was called for
the purpose of inserting a NOP to identify the location of
the inlined function, when ginsnop should have been used.
ginsnop2 is intended to be used before deferreturn to ensure
r2 is properly restored when compiling position independent code.
In some cases the location where r2 is loaded from might not be
initialized. If that happens and r2 is used to generate an address,
the result is likely a SEGV.
This fixes that problem.
Fixes#30283
Change-Id: If70ef27fc65ef31969712422306ac3a57adbd5b6
Reviewed-on: https://go-review.googlesource.com/c/163337
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
info.Name returns a name relative to the directory, so we need to
prefix that directory in the Stat call.
(This was missed in CL 141097 due to the fact that the test only
happened to check symlinks in the current directory.)
This allows the misc/ tests to work in module mode on platforms that
support symlinks.
Updates #30228
Updates #28107
Change-Id: Ie31836382df0cbd7d203b7a8b637c4743d68b6f3
Reviewed-on: https://go-review.googlesource.com/c/163517
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Updates #30228
Change-Id: I830e3c83416b2e5744f30d1a903a74c50462716b
Reviewed-on: https://go-review.googlesource.com/c/163210
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Current assembler reports error when it assembles
"TSTW $1689262177517664, R3", but go1.11 was building
fine.
Fixes#30334
Change-Id: I9c16d36717cd05df2134e8eb5b17edc385aff0a9
Reviewed-on: https://go-review.googlesource.com/c/163259
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ben Shi <powerman1st@163.com>
Consider the following code:
func f(x []*T) interface{} {
return x
}
It returns an interface that holds a heap copy of x (by calling
convT2I or friend), therefore x escape to heap. The current
escape analysis only recognizes that x flows to the result. This
is not sufficient, since if the result does not escape, x's
content may be stack allocated and this will result a
heap-to-stack pointer, which is bad.
Fix this by realizing that if a CONVIFACE escapes and we're
converting from a non-direct interface type, the data needs to
escape to heap.
Running "toolstash -cmp" on std & cmd, the generated machine code
are identical for all packages. However, the export data (escape
tags) differ in the following packages. It looks to me that all
are similar to the "f" above, where the parameter should escape
to heap.
io/ioutil/ioutil.go:118
old: leaking param: r to result ~r1 level=0
new: leaking param: r
image/image.go:943
old: leaking param: p to result ~r0 level=1
new: leaking param content: p
net/url/url.go:200
old: leaking param: s to result ~r2 level=0
new: leaking param: s
(as a consequence)
net/url/url.go:183
old: leaking param: s to result ~r1 level=0
new: leaking param: s
net/url/url.go:194
old: leaking param: s to result ~r1 level=0
new: leaking param: s
net/url/url.go:699
old: leaking param: u to result ~r0 level=1
new: leaking param: u
net/url/url.go:775
old: (*URL).String u does not escape
new: leaking param content: u
net/url/url.go:1038
old: leaking param: u to result ~r0 level=1
new: leaking param: u
net/url/url.go:1099
old: (*URL).MarshalBinary u does not escape
new: leaking param content: u
flag/flag.go:235
old: leaking param: s to result ~r0 level=1
new: leaking param content: s
go/scanner/errors.go:105
old: leaking param: p to result ~r0 level=0
new: leaking param: p
database/sql/sql.go:204
old: leaking param: ns to result ~r0 level=0
new: leaking param: ns
go/constant/value.go:303
old: leaking param: re to result ~r2 level=0, leaking param: im to result ~r2 level=0
new: leaking param: re, leaking param: im
go/constant/value.go:846
old: leaking param: x to result ~r1 level=0
new: leaking param: x
encoding/xml/xml.go:518
old: leaking param: d to result ~r1 level=2
new: leaking param content: d
encoding/xml/xml.go:122
old: leaking param: leaking param: t to result ~r1 level=0
new: leaking param: t
crypto/x509/verify.go:506
old: leaking param: c to result ~r8 level=0
new: leaking param: c
crypto/x509/verify.go:563
old: leaking param: c to result ~r3 level=0, leaking param content: c
new: leaking param: c
crypto/x509/verify.go:615
old: (nothing)
new: leaking closure reference c
crypto/x509/verify.go:996
old: leaking param: c to result ~r1 level=0, leaking param content: c
new: leaking param: c
net/http/filetransport.go:30
old: leaking param: fs to result ~r1 level=0
new: leaking param: fs
net/http/h2_bundle.go:2684
old: leaking param: mh to result ~r0 level=2
new: leaking param content: mh
net/http/h2_bundle.go:7352
old: http2checkConnHeaders req does not escape
new: leaking param content: req
net/http/pprof/pprof.go:221
old: leaking param: name to result ~r1 level=0
new: leaking param: name
cmd/internal/bio/must.go:21
old: leaking param: w to result ~r1 level=0
new: leaking param: w
Fixes#29353.
Change-Id: I7e7798ae773728028b0dcae5bccb3ada51189c68
Reviewed-on: https://go-review.googlesource.com/c/162829
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
vet_test currently uses a custom GOPATH for each test, but it turns
out not to be necessary.
Updates #30228
Change-Id: Id7a7bf6d759bd94adccf44e197be1728c2f23575
Reviewed-on: https://go-review.googlesource.com/c/163038
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
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.
Note that 0123i == 123i for backward-compatibility (and 09i is
valid).
See also the respective language in the spec change:
https://golang.org/cl/161098
Change-Id: I9d2d755cba36a3fa7b9e24308c73754d4568daaf
Reviewed-on: https://go-review.googlesource.com/c/162878
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-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>
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>
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/162819
Reviewed-by: Keith Randall <khr@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>
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>
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>
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/160184
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL introduces compiler support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.
The new Go 2 number literal scanner accepts the following liberal format:
number = [ prefix ] digits [ "." digits ] [ exponent ] [ "i" ] .
prefix = "0" [ "b" |"B" | "o" | "O" | "x" | "X" ] .
digits = { digit | "_" } .
exponent = ( "e" | "E" | "p" | "P" ) [ "+" | "-" ] digits .
If the number starts with "0x" or "0X", digit is any hexadecimal digit;
otherwise, digit is any decimal digit. If the accepted number is not valid,
errors are reported accordingly.
See the new test cases in scanner_test.go for a selection of valid and
invalid numbers and the respective error messages.
R=Go1.13
Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.
Change-Id: Ic8febc7bd4dc5186b16a8c8897691e81125cf0ca
Reviewed-on: https://go-review.googlesource.com/c/157677
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Make it possible to "unread" more than one byte before the most
recently read rune. Use a better name than ungetr2 and make it
slightly more efficient.
R=Go1.13
Change-Id: I45d5dfa11e508259a972ca6560d1f78d7a51fe15
Reviewed-on: https://go-review.googlesource.com/c/158957
Reviewed-by: Russ Cox <rsc@golang.org>
Tooru Takahashi
Keith Randall
Josh Bleecher Snyder
Agniva De Sarker
Michael Fraenkel
Elias Naur
Daniel Martí
Bryan C. Mills
Lynn Boger
fanzha02
Cherry Zhang
Robert Griesemer
Keith Randall
Ian Lance Taylor