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>
Trying to call a method on a nil interface is a panic in Go. For
example:
var stringer fmt.Stringer
println(stringer.String()) // nil pointer dereference
In https://golang.org/cl/143097 we started recovering panics encountered
during function and method calls. However, we didn't handle this case,
as text/template panics before evalCall is ever run.
In particular, reflect's MethodByName will panic if the receiver is of
interface kind and nil:
panic: reflect: Method on nil interface value
Simply add a check for that edge case, and have Template.Execute return
a helpful error. Note that Execute shouldn't just error if the interface
contains a typed nil, since we're able to find a method to call in that
case.
Finally, add regression tests for both the nil and typed nil interface
cases.
Fixes#30143.
Change-Id: Iffb21b40e14ba5fea0fcdd179cd80d1f23cabbab
Reviewed-on: https://go-review.googlesource.com/c/161761
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
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>
We've got away with not copying the testdata directories for the
standard library because the exec wrapper also pushes almost the
entire $GOROOT tree to the device, including testdata directories.
Similar to what the iOS exec wrapper does.
Change-Id: I91ef63ef84a658fc8843002890132c64b7c1d20e
Reviewed-on: https://go-review.googlesource.com/c/163626
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Android emulator builders are soon to join the trybot set. To avoid
flaky runs, work around a longstanding adb bug where concurrent adb
commands sometimes fail.
I haven't seen the problem on actual devices until recently. It seems
that the recently added "adb wait-for-device" can introduce flakyness
with errors such as:
adb: error: failed to get feature set: protocol fault (couldn't read status): Connection reset by peer
Instead of working around that, give up and serialize use of adb
everywhere.
Fixes#23795
Updates #23824
Change-Id: If347c9981fa32ff8a1e14b7454f122ef682450a6
Reviewed-on: https://go-review.googlesource.com/c/163625
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
Use ReverseBytes32 and ReverseBytes64 to speed up these functions.
The byte reversal functions are intrinsics on most platforms and
generally compile to a single instruction.
name old time/op new time/op delta
Reverse32 2.41ns ± 1% 1.94ns ± 3% -19.60% (p=0.000 n=20+19)
Reverse64 3.85ns ± 1% 2.56ns ± 1% -33.32% (p=0.000 n=17+19)
Change-Id: I160bf59a0c7bd5db94114803ec5a59fae448f096
Reviewed-on: https://go-review.googlesource.com/c/159358
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The old code looks suspicious and is fragile.
It would fail if error messages were not totally the same.
Swapped the arguments order to fix that.
Change-Id: Id5df7242fb9224d0090245286ef8986ebb15e921
Reviewed-on: https://go-review.googlesource.com/c/161157
Run-TryBot: Iskander Sharipov <quasilyte@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
If we're accessing a field on a nil struct pointer, and that field is
present in the type, we should print a "nil pointer evaluating X.Y" error
instead of the broader "can't evaluate field Y in X". The latter error
should still be used for the cases where the field is simply missing.
While at it, remove the isNil checks in the struct and map cases. The
indirect func will only return a true isNil when returning a pointer or
interface reflect.Value, so it's impossible for either of these checks
to be useful.
Finally, extend the test suite to test a handful of these edge cases,
including the one shown in the original issue.
Fixes#29137.
Change-Id: I53408ced8a7b53807a0a8461b6baef1cd01d25ae
Reviewed-on: https://go-review.googlesource.com/c/153341
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@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>
The example for Nanoseconds() currently reads:
ns, _ := time.ParseDuration("1000ns")
fmt.Printf("one microsecond has %d nanoseconds.", ns.Nanoseconds())
which is not terribly interesting: it seems obvious that parsing
"1000ns" and then calling Nanoseconds() will print 1000. The mention
of microseconds in the text suggests that the author's intention was,
instead, to write something like this:
u, _ := time.ParseDuration("1us")
i.e. build a time value by parsing 1 microsecond, and then print the
value in nanoseconds. Change the example to do this.
Change-Id: I4ddb123f0935a12cda3b5d6f1ca919bfcd6383d6
Reviewed-on: https://go-review.googlesource.com/c/163622
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I hope that this will fix the tests on iOS, but 'gomote create' isn't
giving me an instance I can test with. (Please patch and test before
approving.)
Updates #15919
Updates #30228
Change-Id: I1b7cd30d5b127a1ad3243b329fa005d229f69a24
Reviewed-on: https://go-review.googlesource.com/c/163726
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <mail@eliasnaur.com>
This CL updates text/template'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: I68c16ea35c3f506701063781388de72bafee6b8d
Reviewed-on: https://go-review.googlesource.com/c/160248
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Griesemer <gri@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>
These source files fail to build with 'go test ./...'.
Move them into testdata so that only test.bash will see them.
Updates #30228
Change-Id: I3673f3cb64b0c128a2bca5fee7679b672fe90770
Reviewed-on: https://go-review.googlesource.com/c/163212
Reviewed-by: Ian Lance Taylor <iant@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>
Using go get prevents the failure case of when the
user doesn't have the repo on their machine.
Change-Id: I9c1174087728b5b06b578b0d52df6eeb7e8c7a3c
Reviewed-on: https://go-review.googlesource.com/c/163718
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
This reverts commit 27b9571de8.
Reason for revert: broke the multi-device Android builder. And the wait logic is moving to the exec wrapper anyway.
Change-Id: I3e429106bbe70b3a12286f8f229a2b558279eec4
Reviewed-on: https://go-review.googlesource.com/c/163620
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change preserves the ability to test misc/cgo/test in GOPATH
mode, at the cost of indirection through a 'go test' subprocess.
Updates #30228
Change-Id: I08de855e62278d30fa622b2f7478e43dd2ab0e96
Reviewed-on: https://go-review.googlesource.com/c/163418
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@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>
If we run 'go test ./...' in the misc module, we don't want to see
errors for these standalone files.
We could instead add +ignore tags to each file individually, but this
is exactly what a testdata directory is for.
Updates #30228
Change-Id: I7047ad888dd6aff701f5982d58b6a79f6a487c58
Reviewed-on: https://go-review.googlesource.com/c/163417
Run-TryBot: Bryan C. Mills <bcmills@google.com>
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>
Nothing in Go can truly guarantee a key will be gone from memory (see
#21865), so remove that claim. That makes Reset useless, because
unlike most Reset methods it doesn't restore the original value state,
so deprecate it.
Change-Id: I6bb0f7f94c7e6dd4c5ac19761bc8e5df1f9ec618
Reviewed-on: https://go-review.googlesource.com/c/162297
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
Adding this early in the cycle to start regression testing in the master
toolchain.
Change-Id: Ia151429c4f94efbac0aa41ab6bc16e7462b0e303
Reviewed-on: https://go-review.googlesource.com/c/163082
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a follow-up on https://golang.org/cl/161199 which introduced
the new Go 2 number literals to text/scanner.
That change introduced a bug by allowing decimal and hexadecimal floats
to be consumed even if the scanner was not configured to accept floats.
This CL changes the code to not consume a radix dot '.' or exponent
unless the scanner is configured to accept floats.
This CL also introduces a new mode "AllowNumberbars" which controls
whether underbars '_' are permitted as digit separators in numbers
or not.
There is a possibility that we may need to refine text/scanner
further (e.g., the Float mode now includes hexadecimal floats
which it didn't recognize before). We're very early in the cycle,
so let's see how it goes.
RELNOTE=yes
Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.
Fixes#30320.
Change-Id: I6481d314f0384e09ef6803ffad38dc529b1e89a3
Reviewed-on: https://go-review.googlesource.com/c/163079
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Revert CL 137055, which changed Clean("\\somepath\dir\") to return
"\\somepath\dir" on Windows. It's not entirely clear this is correct,
as this path is really "\\server\share\", and as such the trailing
slash may be the path on that share, much like "C:\". In any case, the
change broke existing code, so roll it back for now and rethink for 1.13.
Updates #27791Fixes#30307
Change-Id: I69200b1efe38bdb6d452b744582a2bfbb3acbcec
Reviewed-on: https://go-review.googlesource.com/c/163077
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
