We only need to call itabname when actually creating the OCONVIFACE
ops, not any time we test whether a type implements an
interface. Additionally, by moving this call out of implements, we
make it purely based on types, which makes it safe to move to package
types.
Does not pass toolstash -cmp, because it shuffles symbol creation
order.
Change-Id: Iea8e0c9374218f4d97b4339020ebd758d051bd03
Reviewed-on: https://go-review.googlesource.com/c/go/+/279333
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This change adds two examples of using the Read function: one that reads
one metric and one that reads all metrics.
Change-Id: I4940a44c9b1d65f3f7a1554e3145ff07e6492fc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/275855
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Main knows a bit too much about nowritebarrierrec.
Abstract the API a little bit to make the package split easier.
Change-Id: I4b76bdb1fed73dfb0d44e1a6c86de8c2d29a9488
Reviewed-on: https://go-review.googlesource.com/c/go/+/279301
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
isIntrinsicCall and ssaDumpInline are the only two "forward references"
to ssa by earlier phases. Make them a bit more explicit so that the
uses and the definitions can end up in different packages.
Change-Id: I02c7a27464fbedef9fee43c0e4094fa08b4d7a5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/279300
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Separate embed, cgo pragmas, and Main trackScopes variable
from noder more cleanly.
This lets us split embed and noder into new packages.
It also assumes that the local embedded variables will be
removed and deletes them now for simplicity.
Change-Id: I9638bcc2c5f0e76440de056c6285b6aa2f73a00d
Reviewed-on: https://go-review.googlesource.com/c/go/+/279299
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Clean up a TODO (and make the package gc split easier)
by moving the exportsym walk out of iexport proper.
Also move exportsym call out of fninit.
Change-Id: Ie5887a68d325f7154201f4a35b9b4be4bf4b48dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/279298
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There are various global variables tracking the state of the
compilation. Collect them in a single global struct instead.
The struct definition is in package ir, but the struct itself is
still in package gc. It may eventually be threaded through the
code, but in the short term will end up in package typecheck.
Change-Id: I019db07aaedaed2c9b67dd45a4e138dc6028e54c
Reviewed-on: https://go-review.googlesource.com/c/go/+/279297
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Deleting the Pc assignment from Patch is safe because the actual PCs
are not assigned until well after the compiler is done patching jumps.
And it proves that replacing uses of Patch with SetTarget will be safe later.
Change-Id: Iffcbe03f0b5949ccd4c91e79c1272cd06be0f434
Reviewed-on: https://go-review.googlesource.com/c/go/+/279296
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Accumulated fixes to recent changes, to make the code safe
for automated deinterfacing.
Change-Id: I200737046cea88f3356b2402f09e2ca477fb8456
Reviewed-on: https://go-review.googlesource.com/c/go/+/279232
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The list of conflicted files for this merge is:
src/cmd/compile/internal/gc/inl.go
src/cmd/compile/internal/gc/order.go
src/cmd/compile/internal/gc/ssa.go
test/fixedbugs/issue20415.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue28079b.go
inl.go was updated for changes on dev.regabi: namely that OSELRECV has
been removed, and that OSELRECV2 now only uses List, rather than both
Left and List.
order.go was updated IsAutoTmp is now a standalone function, rather
than a method on Node.
ssa.go was similarly updated for new APIs involving package ir.
The tests are all merging upstream additions for gccgo error messages
with changes to cmd/compile's error messages on the dev.regabi branch.
Change-Id: Icaaf186d69da791b5994dbb6688ec989caabec42
On darwin, where we use libc for syscalls, when the runtime exits,
it calls libc exit function, which may call back into user code,
e.g. invoking functions registered with atexit. In particular, it
may call back into Go. But at this point, the Go runtime is
already exiting, so this wouldn't work.
On non-libc platforms we use exit syscall directly, which doesn't
invoke any callbacks. Use _exit on darwin to achieve the same
behavior.
No test for now, as it doesn't pass on all platforms (see trybot
run of PS2).
May fix#42465.
May fix#43294.
Change-Id: Ia1ada22b5da8cb64fdd598d0541eb90e195367eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/269378
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The netbsd kernel has a bug [1] that occassionally prevents netpoll from
waking with netpollBreak, which could result in missing timers for an
unbounded amount of time, as netpoll can't restart with a shorter delay
when an earlier timer is added.
Prior to CL 232298, sysmon could detect these overrun timers and
manually start an M to run them. With this fallback gone, the bug
actually prevents timer execution indefinitely.
As a workaround, we add back sysmon detection only for netbsd.
[1] https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50094
Updates #42515
Change-Id: I8391f5b9dabef03dd1d94c50b3b4b3bd4f889e66
Reviewed-on: https://go-review.googlesource.com/c/go/+/277332
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
This was part of a performance improvement made by CL 232298 to
reduce timer latency. On multiprocessor Plan 9 machines, it triggers
memory faults often enough that the builder test suite never completes
successfully. See issue #42303 for discussion. As shown by the benchmark
result below, worst case latency on plan9_arm is very bad even with the
wakep call in place - in the tickers-per-P=1 case, a 3ms timer is 270ms late.
Skipping the wakep call and running the benchmark again shows some cases
worse, some better. The performance cost doesn't seem excessive for this
temporary workaround which makes the plan9_arm builders usable again.
With wakep call:
cpu% go test -bench Latency time
goos: plan9
goarch: arm
pkg: time
BenchmarkParallelTimerLatency-4 100 10985859 avg-late-ns 18630963 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-4 195 270294688 avg-late-ns 542057670 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-4 234 182452000 avg-late-ns 423933688 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-4 280 193003004 avg-late-ns 408034405 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-4 282 132819086 avg-late-ns 313624570 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-4 339 71152187 avg-late-ns 189014519 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-4 315 26860484 avg-late-ns 101759844 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-4 357 19106739 avg-late-ns 59435620 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-4 376 7246933 avg-late-ns 38888461 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-4 267 40476892 avg-late-ns 205851926 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-4 294 87836303 avg-late-ns 252059695 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-4 379 4127144 avg-late-ns 10494927 max-late-ns
Without wakep call:
BenchmarkParallelTimerLatency-4 61 10775151 avg-late-ns 18668517 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-4 199 299587535 avg-late-ns 597182307 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-4 272 184561831 avg-late-ns 449739837 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-4 235 154983257 avg-late-ns 370940553 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-4 290 150034689 avg-late-ns 332399843 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-4 298 47540764 avg-late-ns 133709031 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-4 350 20379394 avg-late-ns 81742809 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-4 363 14403223 avg-late-ns 98901212 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-4 375 12293090 avg-late-ns 50266552 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-4 336 40628820 avg-late-ns 150946099 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-4 289 88265539 avg-late-ns 280770418 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-4 375 8364937 avg-late-ns 22598421 max-late-ns
Fixes#42303
Change-Id: I70c63cb2a2bad46950a7cd9dfc7bb32943710d32
Reviewed-on: https://go-review.googlesource.com/c/go/+/275672
Reviewed-by: David du Colombier <0intro@gmail.com>
Trust: Michael Pratt <mpratt@google.com>
For #11656
For #43283
Change-Id: I1fcf2b24800f421e36201af43130b487abe605b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/279312
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Previously, reassigned was failing to detect reassignments due to
channel receives in select statements (OSELRECV, OSELRECV2), or due to
standalone 2-value receive assignments (OAS2RECV). This was reported
as a devirtualization panic, but could have caused mis-inlining as
well.
Fixes#43292.
Change-Id: Ic8079c20c0587aeacff9596697fdeba80a697b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/279352
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
The issue11656 code was using the trap instruction as a PC value,
but it is intended to call a PC value that contains the trap instruction.
It doesn't matter too much as in practice the address is not
executable anyhow. But may as well have the code act the way it
is documented to act.
Also, don't run the test with gccgo/GoLLVM, as it can't work.
The illegal instruction will have no unwind data, so the unwinder
won't be able to get past it. In other words, gccgo/GoLLVM suffer
from the exact problem that the issue describes, but it seems insoluble.
For golang/go#11656
Change-Id: Ib2e50ffc91d215fd50e78f742fafe476c92d704e
Reviewed-on: https://go-review.googlesource.com/c/go/+/278473
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The language spec only requires a signed binary exponent of 16 bits
for floating point constants. Permit a "exponent too large" error for
larger exponents.
Don't run test 11326b with gccgo, as it requires successful compilation
of floating point constants with exponents that don't fit in 16 bits.
Change-Id: I98688160c76864aba525a151a14aaaf86bc36a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/279252
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
CL 243940 accidentally broke TestDependencies such that it always passed.
Make it work again, and add a test so that it won't break in the same way.
This revealed that the new embed package was missing from TestDepencies,
so add it.
Fixes#43249
Change-Id: I02b3e38dd35ad88880c4344d46de13b7639aa4c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/279073
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Historically the os package has not imported the strings package.
That was enforced by go/build.TestDependencies, but that test
was accidentally broken (#43249). A dependency of os on strings
was accidentally added by CL 266364; remove it.
For #42026
For #43249
Change-Id: If932308f30561fdcc5c608d7563e849c0d2870d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/279072
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The prealloc map seems to exist to avoid adding a field to all nodes.
Now we can add a field to just the nodes that need the field,
so let's do that and avoid having a magic global with extra node state
that isn't preserved by operations like Copy nor printed by Dump.
This also makes clear which nodes can be prealloc'ed.
In particular, the code in walkstmt looked up an entry in
prealloc using an ONAME node, but there's no code that
ever stores such an entry, so the lookup never succeeded.
Having fields makes that kind of thing easier to see and fix.
Passes buildall w/ toolstash -cmp.
Change-Id: I418ad0e2847615c08868120c13ee719dc0b2eacb
Reviewed-on: https://go-review.googlesource.com/c/go/+/278915
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For globals, Name.Offset is used as a way to address a field within
a global during static initialization. This CL replaces that use with
a separate NameOffsetExpr (ONAMEOFFSET) node.
For locals, Name.Offset is the stack frame offset. This CL calls it
that (FrameOffset, SetFrameOffset).
Now there is no longer any use of Name.Offset or Name.SetOffset.
And now that copies of Names are not being made to change their
offsets, we can lock down use of ir.Copy on Names. The only
remaining uses are during inlining and in handling generic system
functions. At both those times you do want to create a new name
and that can be made explicit by calling the new CloneName method
instead. ir.Copy on a name now panics.
Passes buildall w/ toolstash -cmp.
Change-Id: I0b0a25b9d93aeff7cf4e4025ac53faec7dc8603b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278914
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on sinit.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I3e9458e69a7a9b3f2fe139382bf961bc4473cc42
Reviewed-on: https://go-review.googlesource.com/c/go/+/277928
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on walk.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I7aab57e4077cf10da1994625575c5e42ad114a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/277921
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
ir.Find is called "any" in C#, Dart, Haskell, Python, R, Ruby, and Rust,
and "any_of" in C++, "anyMatch" in Java, "some" in JavaScript,
"exists in OCaml, and "existsb" in Coq.
(Thanks to Matthew Dempsky for the research.)
This CL changes Find to Any to use the mostly standard name.
It also updates wrapper helpers to use the any terminology:
hasCall -> anyCall
hasCallOrChan -> anyCallOrChan
hasSideEffects -> anySideEffects
Unchanged are "hasNamedResults", "hasUniquePos", and "hasDefaultCase",
which are all about a single node, not any node in the IR tree.
I also renamed hasFall to endsInFallthrough, since its semantics are
neither that of "any" nor that of the remaining "has" functions.
So the new terminology helps separate different kinds of predicates nicely.
Change-Id: I9bb3c9ebf060a30447224be09a5c34ad5244ea0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/278912
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Test failures started to happen sporadically on some builds after the introduction of NotifyContext.
To make these tests more robust and avoid the risk of crosstalk we run them in a separate process.
Fixes#41561.
Change-Id: Ia7af105c316afd11765358f1e5e253ccfe2adc2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270198
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Cherry Zhang <cherryyz@google.com>
When doing external linking on Windows, auto-detect the linker flavor
(bfd vs gold vs lld) and when linking with "lld", avoid the use of
"-T" (linker script), since this option is not supported by lld.
[Note: the Go linker currently employs -T to ensure proper placement
of the .debug_gdb_scripts section, to work around issues in older
versions of binutils; LLD recognizes this section and does place it
properly].
Updates #39326.
Change-Id: I3ea79cdceef2316bf86eccdb60188ac3655264ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/278932
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change the run.go driver to recognize the "gc" build tag.
Change existing tests to use the "gc" build tag if they use some
feature that seems specific to the gc compiler, such as passing specific
options to or expecting specific behavior from "go tool compile".
Change tests to use the "!gccgo" build tag if they use "go build" or
"go run", as while those might work with compilers other than gc, they
won't work with the way that gccgo runs its testsuite (which happens
independently of the go command).
For #43252
Change-Id: I666e04b6d7255a77dfc256ee304094e3a6bb15ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/279052
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 269697 was created before CL 276454 and submitted after,
so the api/go1.16.txt file needs to be updated accordingly
to fix the build.
Updates #32406.
Change-Id: I6bf79cc981be504e0baefa82982814aaee4434dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/278992
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Changes from dev.go2go:
+ Removed enableImplicitTParam
+ Fixed a bug in unpackRecv where pointer receivers were not being
detected in the syntax. This didn't seem to actually matter, as I
couldn't produce an incorrect test case as a result of this bug (I
guess by the time method sets are considered, functions have already
been type checked).
+ Updated to the new error API.
+ A line setting t.underlying to Typ[Invalid] was restored in
Checker.validType when a cycle is detected. Though this didn't seem
to matter, it preserves an invariant that invalid types are used to
suppress error reporting.
Change-Id: I3b53b35368c244d67571f23d70fb991af50db540
Reviewed-on: https://go-review.googlesource.com/c/go/+/278595
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The design draft doesn't support this anymore.
Also: Fixed a potential bug in the receiver unpack code
(found by rfindley@).
Change-Id: Ic52eedc686adcb4d5a98884ad0134679c3685c13
Reviewed-on: https://go-review.googlesource.com/c/go/+/278853
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Change-Id: Id7d242ddd4b80a763787513d0a658dd7aea9db7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/276454
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Previous CL uses OSELRECV2 instead of OSELRECV, this CL removes it.
Make this a separated CL as it's not safe for toolstash.
Change-Id: I530ba33fd9311904545e40fe147829af629cf4a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/275459
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
OSELRECV2 can represent all possible receive clauses that can appear
in a select statement, and it simplifies later code, so use it instead.
Follow up CL will remove OSELRECV.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibbdae45287ffd888acd8dc89ca8d99e454277cd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/275458
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL handles all the little files that are left.
Passes buildall w/ toolstash -cmp.
Change-Id: I6588c92dbbdd37342a77b365d70e02134a033d2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/277932
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on noder.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie870126b51558e83c738add8e91a2804ed6d7f92
Reviewed-on: https://go-review.googlesource.com/c/go/+/277931
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on subr.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I435082167c91e20a4d490aa5d5945c7454f71d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/277930
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on range.go, select.go, and swt.go: the big
control structures.
Passes buildall w/ toolstash -cmp.
Change-Id: I033fe056a7b815edb6e8a06f45c12ffd990f4d45
Reviewed-on: https://go-review.googlesource.com/c/go/+/277929
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on const.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I824f18fa0344ddde56df0522f9fa5e237114bbe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/277927
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on inl.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Iaaee7664cd43e264d9e49d252e3afa7cf719939b
Reviewed-on: https://go-review.googlesource.com/c/go/+/277926
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on iimport.go and iexport.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I63edee54991ae5d982e99efa7a2894478d511910
Reviewed-on: https://go-review.googlesource.com/c/go/+/277925
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on escape.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I3e76e1ef9b72f28e3adad9633929699635d852dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/277924
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on ssa.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Iefacc7104dd9469e3c574149791ab0bff29f7fee
Reviewed-on: https://go-review.googlesource.com/c/go/+/277923
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on order.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Ib5731905a620175a6fe978f512da593e0dae9d87
Reviewed-on: https://go-review.googlesource.com/c/go/+/277922
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on typecheck.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I32d1d3b813b0a088b1750c9fd28cd858ed813f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/277920
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It seems clear after using these for a week that Find need not return
anything other than a bool saying whether the target was found.
The main reason for not using the boolean earlier was to avoid confusion
with Inspect: for Find, returning true means "it was found! stop walking"
while for Inspect, returning true means "keep walking the children".
But it turns out that none of the uses of Inspect need the boolean.
This makes sense because types can contain expressions, expressions
can contain statements (inside function literals), and so on, so there
are essentially no times when you can say based on the current AST node
that the children are irrelevant to a particular operation.
So this CL makes two changes:
1) Change Find to return a boolean and to take a callback function
returning a boolean. This simplifies all existing calls to Find.
2) Rename Inspect to Visit and change it to take a callback with no
result at all. This simplifies all existing calls to Inspect.
Removing the boolean result from Inspect's callback avoids having
two callbacks with contradictory boolean results in different APIs.
Renaming Inspect to Visit avoids confusion with ast.Inspect.
Passes buildall w/ toolstash -cmp.
Change-Id: I344ebb5e00b6842012be33e779db483c28e5f350
Reviewed-on: https://go-review.googlesource.com/c/go/+/277919
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The general concept of an "implicit" operation is provided by every
expr representation, but it really only makes sense for a few of them,
and worse the exact definition of what "implicit" means differs from
node to node.
This CL moves the method to each node implementation, although
they all share the same header bit instead of each defining a bool field
that would turn into 8 bytes on 64-bit systems.
Now we can say precisely which Nodes have a meaningful Implicit
method: AddrExpr, CompLitExpr, ConvExpr, ParenExpr, and StarExpr.
Passes buildall w/ toolstash -cmp.
Change-Id: I7d85cb0507a514cdcb6eed21347f362e5fb57a91
Reviewed-on: https://go-review.googlesource.com/c/go/+/277918
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
