[dev.typeparams] all: merge dev.regabi into dev.typeparams

The files below had conflicts that required manual resolution.
The unresolved conflict in noder.go was just in the import
declaration (trivial). All the other conflicts are in tests
where the ERROR regex patterns changed to accomodate gccgo
error messages (incoming from dev.regabi), and to accomodate
types2 in dev.typeparams. They were resolved by accepting the
dev.regabi changes (so as not to lose them) and then by re-
applying whatever changes needed to make them pass with types2.
Finally, the new test mainsig.go was excluded from run.go when
using types2 due to issue #43308.

src/cmd/compile/internal/gc/noder.go
test/fixedbugs/bug13343.go
test/fixedbugs/bug462.go
test/fixedbugs/issue10975.go
test/fixedbugs/issue11326.go
test/fixedbugs/issue11361.go
test/fixedbugs/issue11371.go
test/fixedbugs/issue11674.go
test/fixedbugs/issue13365.go
test/fixedbugs/issue13471.go
test/fixedbugs/issue14136.go
test/fixedbugs/issue14321.go
test/fixedbugs/issue14729.go
test/fixedbugs/issue15898.go
test/fixedbugs/issue16439.go
test/fixedbugs/issue17588.go
test/fixedbugs/issue19323.go
test/fixedbugs/issue19482.go
test/fixedbugs/issue19880.go
test/fixedbugs/issue20185.go
test/fixedbugs/issue20227.go
test/fixedbugs/issue20415.go
test/fixedbugs/issue20749.go
test/fixedbugs/issue22794.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue22921.go
test/fixedbugs/issue23823.go
test/fixedbugs/issue25727.go
test/fixedbugs/issue26616.go
test/fixedbugs/issue28079c.go
test/fixedbugs/issue28450.go
test/fixedbugs/issue30085.go
test/fixedbugs/issue30087.go
test/fixedbugs/issue35291.go
test/fixedbugs/issue38745.go
test/fixedbugs/issue41247.go
test/fixedbugs/issue41440.go
test/fixedbugs/issue41500.go
test/fixedbugs/issue4215.go
test/fixedbugs/issue6402.go
test/fixedbugs/issue6772.go
test/fixedbugs/issue7129.go
test/fixedbugs/issue7150.go
test/fixedbugs/issue7153.go
test/fixedbugs/issue7310.go
test/fixedbugs/issue8183.go
test/fixedbugs/issue8385.go
test/fixedbugs/issue8438.go
test/fixedbugs/issue8440.go
test/fixedbugs/issue8507.go
test/fixedbugs/issue9370.go
test/fixedbugs/issue9521.go

Change-Id: I26e6e326fde6e3fca5400711a253834d710ab7f4

Merge "[dev.regabi] all: merge master into dev.regabi" into dev.regabi

[dev.regabi] cmd/compile: separate nowritebarrierrec from main

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>

[dev.regabi] cmd/compile: separate ssa from other phases

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>

[dev.regabi] cmd/compile: separate noder more cleanly

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>

[dev.regabi] cmd/compile: separate exportsym more cleanly

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>

[dev.regabi] cmd/compile: collect global compilation state

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>

[dev.regabi] cmd/compile: setup to move Addrconst, Patch into cmd/internal/obj

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>

[dev.regabi] cmd/compile: cleanup for concrete types - more

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>

[dev.regabi] all: merge master into dev.regabi

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

cmd/compile: recognize reassignments involving receives

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>

test: for issue11656 try to execute trap, not call it

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>

test: permit "exponent too large" error

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>

go/build: make TestDependencies work again

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>

os: remove dependency on strings package

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>

[dev.regabi] cmd/compile: remove prealloc map

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>

[dev.regabi] cmd/compile: remove uses of Name.Offset, Name.copy

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>

[dev.regabi] cmd/compile: add ONAMEOFFSET, delete to-be-deleted fields

Breaks toolstash but clearly no effect.

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

[dev.regabi] cmd/compile: cleanup for concrete types - sinit

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>

[dev.regabi] cmd/compile: cleanup for concrete types - walk

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>

[dev.regabi] cmd/compile: rename ir.Find to ir.Any and update uses

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>

os/signal: fix flaky tests for NotifyContext.

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>

cmd/link: avoid use of -T when linking with lld

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>

test: recognize and use gc build tag

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>

api/go1.16: remove crypto/tls APIs that are moved to Go 1.17

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>

crypto/tls: revert "add HandshakeContext method to Conn"

This reverts CL 246338.

Reason for revert: waiting for 1.17 release cycle

Updates #32406

Change-Id: I074379039041e086c62271d689b4b7f442281663
Reviewed-on: https://go-review.googlesource.com/c/go/+/269697
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>

[dev.typeparams] go/types: import object resolution from dev.go2go

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>

[dev.typeparams] cmd/compile/internal/types2: remove code for implicit type arguments

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>

api: promote next to go1.16

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>

[dev.regabi] cmd/compile: remove OSELRECV

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>

[dev.regabi] cmd/compile: use OSELRECV2 for all <-c variants

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>

[dev.regabi] cmd/compile: add type assertion in regabi test

Change-Id: I7da5165f3679736040be5bfbcea3d4a85deaff2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/277957
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: cleanup for concrete types - mop-up

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>

[dev.regabi] cmd/compile: cleanup for concrete types - noder

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>

[dev.regabi] cmd/compile: cleanup for concrete types - subr

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>

[dev.regabi] cmd/compile: cleanup for concrete types - range, select, swt

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>

[dev.regabi] cmd/compile: cleanup for concrete types - const

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>

[dev.regabi] cmd/compile: cleanup for concrete types - inl

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>

[dev.regabi] cmd/compile: cleanup for concrete types - import/export

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>

[dev.regabi] cmd/compile: cleanup for concrete types - escape

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>

[dev.regabi] cmd/compile: cleanup for concrete types - ssa

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>

[dev.regabi] cmd/compile: cleanup for concrete types - order

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>

[dev.regabi] cmd/compile: cleanup for concrete types - typecheck

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>

[dev.regabi] cmd/compile: simplify ir.Find, replace ir.Inspect with ir.Visit

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>

[dev.regabi] cmd/compile: limit Implicit method to nodes where it is defined

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>

[dev.regabi] cmd/compile: remove use of Initorder, Offset Node fields for initorder

The initorder pass is already making heavy use of maps,
and it is concerned with relatively few nodes (only the assignments
in package-level variable declarations). The tracking of init order
for these nodes can be done with another map instead of storing
the bits directly in the Node representations.

This will let us drop Offset_ from AssignStmt and AssignListStmt
and drop Initorder from all nodes.

Passes buildall w/ toolstash -cmp.

Change-Id: I151c64e84670292c2004da4e8e3d0660a88e3df3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277917
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: change Nodes to be a slice

The Nodes type originally served two purposes:
(1) It provided a representation optimized for empty slices,
allocating only a single word in that case instead of three,
at the cost of a non-empty slice being four words instead of three.
This was particularly important with the old Node representation,
in which most Nodes were full of unused fields.
(2) It provided a few useful helper methods beyond what can be
done with slices.

The downside of Nodes is that the API is a bit overwhelming,
with many ways to spell ordinary slice operations. For example,
reassigning the first node in the list can be done with:

ns.Slice()[0] = n
ns.SetIndex(0, n)
ns.SetFirst(n)
*ns.Addr(0) = n

And APIs must decide whether to use Nodes or []ir.Node and
then conversions must be inserted when crossing the boundary.

Now that Node structs are specialized to opcode and most Nodes
lists are actually non-empty, it makes sense to simplify Nodes
to make it actually a slice type, so that ordinary slice operations can
be used, and assignments can automatically convert between
Nodes and []ir.Node.

This CL changes the representation to be a slice and adds a new
Take method, which returns the old slice and clears the receiver.

In a future CL, the Nodes method set will simplify down to:

Copy
Take
Append
Prepend
Format

with the current methods being rewritten:

ns.Len() -> len(ns)
ns.Slice() -> ns
ns.First() -> ns[0]
ns.Second() -> ns[1]
ns.Index(i) -> ns[i]
ns.Addr(i) -> &ns[i]
ns.SetIndex(i, n) -> ns[i] = n
ns.SetFirst(n) -> ns[0] = n
ns.SetSecond(n) -> ns[1] = n
ns.Set1(n) -> ns = []Node{n}
ns.Set2(n, n2) -> ns = []Node{n, n2}
ns.Set3(n, n2, n3) -> ns = []Node{n, n2, n3}
AsNodes(slice) -> Nodes(slice)
ns.AppendNodes(pns) -> ns.Append(pns.Take()...)
ns.MoveNodes(pns) -> ns = pns.Take()

and then all those other methods will be deleted.

Simplifying the API down to just those five methods will also make it
more reasonable to introduce more specialized slices like Exprs and Stmts
at some point in the future.

But again this CL just changes the representation to a slice,
introduces Take, and leaves the rest alone.

Passes buildall w/ toolstash -cmp.

Change-Id: I309ab8335c69bb582d811c92c17f938dd6e0c4fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/277916
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: update ir/fmt for concrete types

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 package fmt. There are various type assertions
but also some rewriting to lean more heavily on reflection.

Passes buildall w/ toolstash -cmp.

Change-Id: I503467468b42ace11bff2ba014b03cfa345e6d03
Reviewed-on: https://go-review.googlesource.com/c/go/+/277915
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: fix potential closure waste in Order

I haven't measured this, but it's the only use of EditChildren
where we aren't careful to allocate a closure once and use it
for the whole recursion. This one is allocating a closure at
every level of the recursion, and it was an oversight that it
wasn't cleaned up in the original CL.

Passes buildall w/ toolstash -cmp.

Change-Id: I5e3f1795c6f64c5867a19c077f797643aa1066a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277914
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: rewrite some generic ir.Nod calls

An automated rewrite is going to remove the bulk of the calls
to ir.Nod and friends. This CL takes care of the ones that don't
have fixed opcodes and so aren't amenable to automatic rewriting.

Passes buildall w/ toolstash -cmp.

Replay of CL 275886, lost to the bad-merge history rewrite.

Change-Id: I5bf8d1d182f847f4ab44b7e278b752913e30e4c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/277956
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: cleanup preparing for concrete types, 2

Avoid using the same variable for two different concrete
Node types in other files (beyond walk). This will smooth the
introduction of specific constructors, replacing ir.Nod and friends.

Passes buildall w/ toolstash -cmp.

Replay of CL 275885, lost to the bad-merge history rewrite.

Change-Id: I0da89502a0bd636b8766f01b6f843c7821b3e9ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/277955
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: cleanup preparing for concrete types

Avoid using the same variable for two different concrete
Node types in walk. This will smooth the introduction of
specific constructors, replacing ir.Nod and friends.

Passes buildall w/ toolstash -cmp.

Replay of CL 275884, lost to the bad-merge history rewrite.

Change-Id: I05628e20a19c9559ed7478526ef6cb2613f735e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/277954
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

html/template: avoid race when escaping updates template

Fixes #39807

Change-Id: Icf384f800e2541bc753507daa3a9bc7e5d1c3f79
Reviewed-on: https://go-review.googlesource.com/c/go/+/274450
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roberto Clapis <roberto@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

go/types: report error for invalid (but empty) expr switch

This is a port of CL 278132 from the dev.typeparams branch. A notable
addition is a new error code, since no existing codes made sense and we
have an analogous code for type switches.

Fixes #43110

Change-Id: I22b3f9d8777063223f82785504e8b7d299bc5216
Reviewed-on: https://go-review.googlesource.com/c/go/+/278813
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>

[dev.typeparams] cmd/compile/internal/syntax: don't panic when providing -verify

The -verify flag is used to verify idempotent printing of syntax
trees. While syntax tree printing is not actively used at the
moment, the verification code still shouldn't panic.

Fixed the cause for the panic (after reading from a bytes.Buffer
that buffer is empty and so doesn't compare to the unread buffer),
and replaced the panic with a test error.

Added a test that makes sure the code invoked by -verify is run.

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

[dev.typeparams] cmd/compile/internal/syntax: type parameters must always be named

Report an error otherwise.

Change-Id: Ia76ea03a3f26b13dd9bca49f7bd42101d1ff1f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/278475
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

[dev.typeparams] cmd/compile/internal/types2: review of predicates.go

Make predicates.go match the corresponding and reviewed go/types version.

The remaining diffs are due to the difference in the implementations
of the type conversion methods/functions:

$ diff $GOROOT/src/cmd/compile/internal/types2/predicates.go $GOROOT/src/go/types/predicates.go
7c7
< package types2
---
> package types
9a10
>  "go/token"
32c33
<  switch t := optype(typ.Under()).(type) {
---
>  switch t := optype(typ).(type) {
63c64
<  // set up. Must not call Basic()!
---
>  // set up. Must not call asBasic()!
79c80
<  t := typ.Basic()
---
>  t := asBasic(typ)
85c86
<  return typ.Interface() != nil
---
>  return asInterface(typ) != nil
110c111
<  if t := T.TypeParam(); t != nil && optype(t) == theTop {
---
>  if t := asTypeParam(T); t != nil && optype(t) == theTop {
114c115
<  switch t := optype(T.Under()).(type) {
---
>  switch t := optype(T).(type) {
143c144
<  switch t := optype(typ.Under()).(type) {
---
>  switch t := optype(typ).(type) {
300,301c301,302
<  check.completeInterface(nopos, x)
<  check.completeInterface(nopos, y)
---
>  check.completeInterface(token.NoPos, x)
>  check.completeInterface(token.NoPos, y)

Change-Id: I174d8a8a22fbd8814ede25002cb2705588912329
Reviewed-on: https://go-review.googlesource.com/c/go/+/278474
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

[dev.typeparams] go/types: import predicates.go from dev.go2go

Changes from dev.go2go:
 + Update some isComparable cases to use the seen map.
 + Tiny updates to comments.

Change-Id: Iafd85d60835f17a87f514d9774cae07c183ee6cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/278594
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

[dev.typeparams] cmd/compile/internal/types2: review of unify.go

Make unify.go match the corresponding and reviewed go/types version.
The remaining differences are due to other differences in the packages.
Also, this version of unify opted to preserve the longer comment around
case tj > 0.

$ diff $GOROOT/src/cmd/compile/internal/types2/unify.go $GOROOT/src/go/types/unify.go
7c7
< package types2
---
> package types
9c9,12
< import "sort"
---
> import (
>  "go/token"
>  "sort"
> )
120,123d122
<  // This case is handled like the default case.
<  // case tj > 0:
<  //  // Only the type parameter for y has an inferred type. Use y slot for x.
<  //  u.x.setIndex(i, tj)
125,126c124,125
<  // Neither type parameter has an inferred type. Use y slot for x
<  // (or x slot for y, it doesn't matter).
---
>  // Either the type parameter for y has an inferred type, or neither type
>  // parameter has an inferred type. In either case, use y slot for x.
216c215
<  // basic types and type parameters. We use Named() because we only
---
>  // basic types and type parameters. We use asNamed() because we only
219,222c218,221
<  case !isNamed(x) && y != nil && y.Named() != nil:
<  return u.nify(x, y.Under(), p)
<  case x != nil && x.Named() != nil && !isNamed(y):
<  return u.nify(x.Under(), y, p)
---
>  case !isNamed(x) && y != nil && asNamed(y) != nil:
>  return u.nify(x, under(y), p)
>  case x != nil && asNamed(x) != nil && !isNamed(y):
>  return u.nify(under(x), y, p)
353,354c352,353
<  u.check.completeInterface(nopos, x)
<  u.check.completeInterface(nopos, y)
---
>  u.check.completeInterface(token.NoPos, x)
>  u.check.completeInterface(token.NoPos, y)

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

cmd/link: handle large relocation addend on darwin/arm64

Mach-O relocation addend is signed 24-bit. When external linking,
if the addend is larger, we cannot put it directly into a Mach-O
relocation. This CL handles large addend by creating "label"
symbols at sym+0x800000, sym+(0x800000*2), etc., and emitting
Mach-O relocations that target the label symbols with a smaller
addend. The label symbols are generated late (similar to what
we do for RISC-V64).

One complexity comes from handling of carrier symbols, which does
not track its size or its inner symbols. But relocations can
target them. We track them in a side table (similar to what we
do for XCOFF, xcoffUpdateOuterSize).

Fixes #42738.

Change-Id: I8c53ab2397f8b88870d26f00e9026285e5ff5584
Reviewed-on: https://go-review.googlesource.com/c/go/+/278332
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

cmd/link: pass arch-specific flags to external linker when testing supported flag

When testing if a flag (e.g. "-no-pie") is supported by the
external linker, pass arch-specific flags (like "-marm").

In particular, on the ARM builder, if CGO_LDFLAGS=-march=armv6
is set, the C toolchain fails to build if -marm is not passed.

# cc -march=armv6 1.c
1.c: In function 'main':
1.c:3:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
 int main() {
 ^~~

This makes the Go linker think "-no-pie" is not supported when it
actually is.

Passing -marm makes it work.

Fixes #43202.

Change-Id: I4e8b71f08818993cbbcb2494b310c68d812d6b50
Reviewed-on: https://go-review.googlesource.com/c/go/+/278592
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

cmd/internal/goobj: fix buglet in object file reader

The code in the new (introduced in 1.15) Go object file reader was
casting a pointer-mmaped-memory into a large array prior to performing
a read of the relocations section:

return (*[1<<20]Reloc)(unsafe.Pointer(&r.b[off]))[:n:n]

For very large object files, this artificial array isn't large enough
(that is, there are more than 1048576 relocs to read), so update the
code to use a larger artifical array size.

Fixes #41621.

Change-Id: Ic047c8aef4f8a3839f2e7e3594bce652ebd6bd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278492
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Than McIntosh <thanm@google.com>

doc/go1.16: add link to reflect.StructTag

For #40700.

Change-Id: I67dd55b435304e428929c9a54b8881f9b78efdfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/278392
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

net: close connection in localServer teardown

The transponder sets up a deferred close on accepted connections which
is fine after the client reads all data. However there are no mutexes
nor channels to block the transponder from closing. If the scheduler
runs close before the client read, it will cause an EOF failure.

Fixes #42720

Change-Id: Ic21b476c5efc9265a80a2c6f8484efdb5af66405
Reviewed-on: https://go-review.googlesource.com/c/go/+/273672
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Damien Neil <dneil@google.com>

[dev.typeparams] go/types: import some support functions from dev.go2go

Import dev.go2go changes for exprstring.go, sizes.go, and scope.go.
These files have been reviewed, but are unmodified.

Change-Id: I9df9f8967bab73ce535a539b049346a872877572
Reviewed-on: https://go-review.googlesource.com/c/go/+/278593
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

cmd/link: ignore SEH marking on PE objects

Microsoft's linker looks at whether all input objects have an empty
section called @feat.00. If all of them do, then it enables SEH;
otherwise it doesn't enable that feature. So, since around the Windows
XP SP2 era, most tools that make PE objects just tack on that section,
so that it won't gimp Microsoft's linker logic. Go doesn't support SEH,
so in theory, none of this really matters to us. But actually, if the
linker tries to ingest an object with @feat.00 -- which are produced by
LLVM's resource compiler, for example -- it chokes because of the
IMAGE_SYM_ABSOLUTE section that it doesn't know how to deal with. Since
@feat.00 is just a marking anyway, skip IMAGE_SYM_ABSOLUTE sections that
are called @feat.00.

Change-Id: I1d7bfcf6001186c53e2c487c5ac251ca65efefee
Reviewed-on: https://go-review.googlesource.com/c/go/+/268239
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>

[dev.typeparams] go/types: import lookup logic from dev.go2go

Changes from dev.go2go:
 + Remove support for pointer designation.
 + Remove support for method type parameters in missingMethod. We could
   leave this logic in, but it looked sufficiently shaky that I'd rather
   not bring in the additional complexity.
 + Remove the strictness flag parameter to assertableTo, since it isn't
   used.

Change-Id: I812b8d1c49f3b714b166f061fbb7f2e683a0ce86
Reviewed-on: https://go-review.googlesource.com/c/go/+/278333
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

test: update for gofrontend error message changes

fixedbugs/bug195.go:9:20: error: interface contains embedded non-interface
fixedbugs/bug195.go:12:20: error: interface contains embedded non-interface
fixedbugs/bug195.go:15:22: error: interface contains embedded non-interface
fixedbugs/bug195.go:18:9: error: invalid recursive interface
fixedbugs/bug195.go:26:9: error: invalid recursive interface

fixedbugs/bug251.go:15:9: error: invalid recursive interface

fixedbugs/issue23823.go:15:9: error: invalid recursive interface

Change-Id: If4c22430557459d5b361beda7168f8cb42b58811
Reviewed-on: https://go-review.googlesource.com/c/go/+/278512
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

doc/go1.15: mention 1.15.3 cgo restriction on empty structs

For #40954

Change-Id: I6a30aed31a16e820817f4ca5c7f591222e922946
Reviewed-on: https://go-review.googlesource.com/c/go/+/277432
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

test: match gofrontend error messages

fixedbugs/issue11614.go:14:9: error: interface contains embedded non-interface
fixedbugs/issue11614.go:22:20: error: interface contains embedded non-interface

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

test: only require issue11674 errors with gc compiler

The gofrontend code sees that the denominator is not zero,
so it computes the values. Dividing zero by a non-zero value
produces zero. The language spec doesn't require any of these
cases to report an error, so make the errors compiler-specific.

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

test: remove bug429 (duplicates runtime.TestSimpleDeadlock)

The bug429 tests is an exact duplicate of TestSimpleDeadlock in the
runtime package. The runtime package is the right place for this test,
and the version in the runtime package will run faster as the build
step is combined with other runtime package tests.

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

test: adjust issue11371 to fit in required precision

The language spec only requires that floating point values be
represented with 256 bits, which is about 1e75. The issue11371 test
was assuming that the compiler could represent 1e100. Adjusting the
test so that it only assumes 256 bits of precision still keeps the
test valid, and permits it to pass when using the gofrontend.

Change-Id: I9d1006e9adc9438277f4b8002488c912e5d61cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/278116
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

test: only check for issue11362 error with gc

With the gc compiler the import path implies the package path,
so keeping a canonical path is important.  With the gofrontend
this is not the case, so we don't need to report this as a bug.

Change-Id: I245e34f9b66383bd17e79438d4b002a3e20aa994
Reviewed-on: https://go-review.googlesource.com/c/go/+/278115
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

test: import file name for issue19028

The pattern in NNN.dir directories is that if we have a.go,
the other files import "./a". For gc it happens to work to use a path,
but not for gofrontend. Better to be consistent.

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

[dev.typeparams] go/types: import changes to types.Info from dev.go2go

Import changes related to tracking type inferences and sanitizing
types.Info from the dev.go2go branch. Notably, the following were all
intentionally omitted from this import:
 + types.Error.Full is not imported, due to it being a public API that
   requires some further thought.
 + The Config.AcceptMethodTypeParams, InferFromConstraints, and Trace
   flag are not imported. The expectation is that we will not accept
   method type parameters for now, will always infer from constraints,
   and will continue to use the trace constant to guard tracing.
 + Some trace annotations are not imported to from the checking pass. We
   can add them back later, but for now they seemed verbose.
 + Checker.useBrackets is removed. This is no longer configurable.

Change-Id: I7f6315d66b200c92ffd1e55c9fd425a5d99149ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/278312
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

[dev.typeparams] cmd/compile/internal/types2: don't crash if import path is missing

In package syntax:
- fix parser appendGroup to not add nil entries
- non-string paths are syntax errors per the spec; report in parser
- document ImportDecl.Path invariants

In package types2:
- guard against absent paths

In package gc:
- guard against absent paths

Fixes #43190.

Change-Id: Ic6a06f6a96b7f519feaa1ceaf4376fc5ab0f0129
Reviewed-on: https://go-review.googlesource.com/c/go/+/278114
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

[dev.typeparams] cmd/compile/internal/types2: report error for invalid (but empty) expr switch

Enable one more errorcheck test.

Updates #43110.
Updates #43200.

Change-Id: Ib7b971d5e9989c65320579f75d65266bbbbeec53
Reviewed-on: https://go-review.googlesource.com/c/go/+/278132
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

doc/go1.16: fix path, path/filepath release notes

The path package doesn't have a Glob function. Adjust the release notes
re. CL 264397 accordingly.

Also add links to the documentation of all mentioned functions.

For #40700.

Change-Id: Ibf3e0530fa6fab36a3f6fbc664f0800869ce9ec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/278213
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

doc/go1.16: fix formatting in net, net/http and net/http/httputil sections

For #40700.

Change-Id: I83d9ef9f79d59a0165a47ccc938fc2bf40e90703
Reviewed-on: https://go-review.googlesource.com/c/go/+/278212
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

[dev.typeparams] go/types: import unify.go and infer.go from dev.go2go

After review, the only non-superficial change was to delegate the call
to under(...) to structuralType. Otherwise, update a few stale comments:
 + correct indices in the documentation for tparamsList
 + update smap->substMap in a few places
 + update type parameter syntax in a couple places

I've spent a good amount of time reviewing this code, and it
fundamentally LGTM (though I wish we didn't have to copy the logic from
identical0). However, as demonstrated in #43056, this code is
complicated and not always easy to reason about, particularly in the
context of type checking where not all types may be complete.

To further understand and verify this code I'd like to write more tests,
but that must wait until the rest of the changes in go/types are
imported from dev.go2go.

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

text/template: error on range over send channel

template range require channel contains RecvDir
if recv on send only channel will raise an panic.

Fixes #43065

Change-Id: Ie0ea70ce60e074bf8c9f2378e07ef1d4c41dc38f
Reviewed-on: https://go-review.googlesource.com/c/go/+/276532
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

[dev.regabi] cmd/compile: use ir.Ident for imported identifiers

This CL substantially reworks how imported declarations are handled,
and fixes a number of issues with dot imports. In particular:

1. It eliminates the stub ir.Name declarations that are created
upfront during import-declaration processing, allowing this to be
deferred to when the declarations are actually needed. (Eventually,
this can be deferred even further so we never have to create ir.Names
w/ ONONAME, but this CL is already invasive/subtle enough.)

2. During noding, we now use ir.Idents to represent uses of imported
declarations, including of dot-imported declarations.

3. Unused dot imports are now reported after type checking, so that we
can correctly distinguish whether composite literal keys are a simple
identifier (struct literals) or expressions (array/slice/map literals)
and whether it might be a use of a dot-imported declaration.

4. It changes the "redeclared" error messages to report the previous
position information in the same style as other compiler error
messages that reference other source lines.

Passes buildall w/ toolstash -cmp.

Fixes #6428.
Fixes #43164.
Fixes #43167.
Updates #42990.

Change-Id: I40a0a780ec40daf5700fbc3cfeeb7300e1055981
Reviewed-on: https://go-review.googlesource.com/c/go/+/277713
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>

[dev.regabi] cmd/compile: type check externdcl earlier

The next CL requires externdcl to be type checked earlier, but this
causes toolstash -cmp to complain because it causes src.PosBases to
get added in a different order. So split out into a separate CL.

Change-Id: Icab4eadd3fa8acffbd3e980bd8100924378351b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277732
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[dev.regabi] cmd/compile: fix latent Sym.SetPkgDef issue

Sym.pkgDefPtr is supposed to return a pointer to the types.Object
variable currently holding the Sym's package-scope
definition. However, in the case of identifiers that were shadowed in
the current scope, it was incorrectly returning a pointer to a stack
copy of the dclstack variable, rather than a pointer into the dclstack
itself.

This doesn't affect PkgDef, because it only reads from the variable,
so it got the same result anyway. It also happens to not affect our
usage of SetPkgDef today, because we currently only call SetPkgDef for
the builtin/runtime.go symbols, and those are never shadowed.

However, it does affect my upcoming CL to lazily create the ir.Names
for imported objects, as that depends on the ability to use SetPkgDef
to set shadowed identifiers.

Passes buildall w/ toolstash -cmp.

Change-Id: I54fc48b33da0670d31725faa1df1170a8730750a
Reviewed-on: https://go-review.googlesource.com/c/go/+/277712
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

test: recognize gofrontend error messages

fixedbugs/issue26416.go:24:16: error: unknown field ‘t1f1’ in ‘t2’
fixedbugs/issue26416.go:25:16: error: unknown field ‘t1f2’ in ‘t3’
fixedbugs/issue26416.go:26:16: error: unknown field ‘t2f1’ in ‘t3’

fixedbugs/issue26616.go:15:9: error: single variable set to multiple-value function call
fixedbugs/issue26616.go:9:5: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:12:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:13:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:15:9: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:14:11: error: incompatible types in assignment (multiple-value function call in single-value context)

fixedbugs/issue26855.go:23:12: error: incompatible type for field 1 in struct construction
fixedbugs/issue26855.go:27:12: error: incompatible type for field 1 in struct construction

fixedbugs/issue25958.go:14:18: error: expected ‘<-’ or ‘=’
fixedbugs/issue25958.go:15:35: error: expected ‘<-’ or ‘=’

fixedbugs/issue28079b.go:13:9: error: array bound is not constant
fixedbugs/issue28079b.go:16:22: error: invalid context-determined non-integer type for left operand of shift

fixedbugs/issue28079c.go:14:22: error: invalid context-determined non-integer type for left operand of shift

fixedbugs/issue28450.go:9:19: error: ‘...’ only permits one name
fixedbugs/issue28450.go:10:18: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:16: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:24: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:13:25: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:15:19: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:21: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:31: error: ‘...’ must be last parameter

fixedbugs/issue28268.go:20:1: error: method ‘E’ redeclares struct field name
fixedbugs/issue28268.go:19:1: error: method ‘b’ redeclares struct field name

fixedbugs/issue27356.go:14:14: error: expected function
fixedbugs/issue27356.go:18:9: error: expected function

fixedbugs/issue29855.go:13:11: error: unknown field ‘Name’ in ‘T’

fixedbugs/issue27938.go:14:15: error: expected package
fixedbugs/issue27938.go:18:13: error: expected package
fixedbugs/issue27938.go:22:13: error: expected package
fixedbugs/issue27938.go:22:9: error: expected signature or type name

fixedbugs/issue29870b.go:13:9: error: ‘x’ declared but not used

fixedbugs/issue30085.go:10:18: error: wrong number of initializations
fixedbugs/issue30085.go:11:21: error: wrong number of initializations

fixedbugs/issue30087.go:10:18: error: wrong number of initializations
fixedbugs/issue30087.go:11:11: error: number of variables does not match number of values
fixedbugs/issue30087.go:12:9: error: wrong number of initializations
fixedbugs/issue30087.go:13:9: error: wrong number of initializations

fixedbugs/issue28926.go:16:14: error: use of undefined type ‘G’
fixedbugs/issue28926.go:18:14: error: use of undefined type ‘E’
fixedbugs/issue28926.go:22:24: error: use of undefined type ‘T’

fixedbugs/issue30722.go:13:13: error: invalid numeric literal
fixedbugs/issue30722.go:14:13: error: invalid numeric literal
fixedbugs/issue30722.go:15:13: error: invalid numeric literal

fixedbugs/issue33308.go:12:19: error: invalid context-determined non-integer type for left operand of shift

fixedbugs/issue33386.go:16:9: error: expected operand
fixedbugs/issue33386.go:22:9: error: expected operand
fixedbugs/issue33386.go:26:17: error: expected operand
fixedbugs/issue33386.go:27:18: error: expected operand
fixedbugs/issue33386.go:28:29: error: expected operand
fixedbugs/issue33386.go:15:17: error: reference to undefined name ‘send’
fixedbugs/issue33386.go:27:13: error: reference to undefined name ‘a’
fixedbugs/issue33386.go:21:19: error: value computed is not used

fixedbugs/issue33460.go:34:10: error: duplicate key in map literal
fixedbugs/issue33460.go:21:9: error: duplicate case in switch
fixedbugs/issue33460.go:24:9: error: duplicate case in switch
fixedbugs/issue33460.go:25:9: error: duplicate case in switch

fixedbugs/issue32723.go:12:14: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:13:13: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:16:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:17:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:18:15: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:21:15: error: invalid comparison of non-ordered type

fixedbugs/issue35291.go:13:9: error: duplicate value for index 1

fixedbugs/issue38745.go:12:12: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:13:16: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:19: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:9: error: not enough arguments to return

fixedbugs/issue41500.go:16:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:17:26: error: incompatible types in binary expression
fixedbugs/issue41500.go:18:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:19:26: error: incompatible types in binary expression

fixedbugs/issue41575.go:23:6: error: invalid recursive type
fixedbugs/issue41575.go:9:6: error: invalid recursive type ‘T1’
fixedbugs/issue41575.go:13:6: error: invalid recursive type ‘T2’
fixedbugs/issue41575.go:17:6: error: invalid recursive type ‘a’
fixedbugs/issue41575.go:18:6: error: invalid recursive type ‘b’
fixedbugs/issue41575.go:19:6: error: invalid recursive type ‘c’
fixedbugs/issue41575.go:25:6: error: invalid recursive type ‘g’
fixedbugs/issue41575.go:32:6: error: invalid recursive type ‘x’
fixedbugs/issue41575.go:33:6: error: invalid recursive type ‘y’

fixedbugs/issue4215.go:10:9: error: not enough arguments to return
fixedbugs/issue4215.go:14:9: error: return with value in function with no return type
fixedbugs/issue4215.go:19:17: error: not enough arguments to return
fixedbugs/issue4215.go:21:9: error: not enough arguments to return
fixedbugs/issue4215.go:27:17: error: not enough arguments to return
fixedbugs/issue4215.go:29:17: error: too many values in return statement
fixedbugs/issue4215.go:31:17: error: not enough arguments to return
fixedbugs/issue4215.go:43:17: error: not enough arguments to return
fixedbugs/issue4215.go:46:17: error: not enough arguments to return
fixedbugs/issue4215.go:48:9: error: too many values in return statement
fixedbugs/issue4215.go:52:9: error: too many values in return statement

fixedbugs/issue41247.go:10:16: error: incompatible type for return value 1

fixedbugs/issue41440.go:13:9: error: too many arguments

fixedbugs/issue6772.go:10:16: error: ‘a’ repeated on left side of :=
fixedbugs/issue6772.go:17:16: error: ‘a’ repeated on left side of :=

fixedbugs/issue6402.go:12:16: error: incompatible type for return value 1

fixedbugs/issue6403.go:13:23: error: reference to undefined identifier ‘syscall.X’
fixedbugs/issue6403.go:14:15: error: reference to undefined name ‘voidpkg’

fixedbugs/issue7746.go:24:20: error: constant multiplication overflow

fixedbugs/issue7760.go:15:7: error: invalid constant type
fixedbugs/issue7760.go:16:7: error: invalid constant type
fixedbugs/issue7760.go:18:7: error: invalid constant type
fixedbugs/issue7760.go:19:7: error: invalid constant type
fixedbugs/issue7760.go:21:11: error: expression is not constant
fixedbugs/issue7760.go:22:11: error: expression is not constant
fixedbugs/issue7760.go:24:7: error: invalid constant type
fixedbugs/issue7760.go:25:7: error: invalid constant type

fixedbugs/issue7129.go:18:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:19:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:17: error: argument 2 has incompatible type (cannot use type bool as type int)

fixedbugs/issue7150.go:12:20: error: index expression is negative
fixedbugs/issue7150.go:13:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:14:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:15:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:16:13: error: some element keys in composite literal are out of range

fixedbugs/issue7675.go:16:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:16:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:16:9: error: not enough arguments
fixedbugs/issue7675.go:16:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:18:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:18:28: error: argument 4 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:9: error: too many arguments
fixedbugs/issue7675.go:18:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:19:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:19:9: error: not enough arguments
fixedbugs/issue7675.go:19:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:21:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:21:19: error: argument 3 has incompatible type
fixedbugs/issue7675.go:21:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:23:14: error: floating-point constant truncated to integer

fixedbugs/issue7153.go:11:15: error: reference to undefined name ‘a’
fixedbugs/issue7153.go:11:18: error: incompatible type for element 1 in composite literal
fixedbugs/issue7153.go:11:24: error: incompatible type for element 2 in composite literal

fixedbugs/issue7310.go:12:13: error: left argument must be a slice
fixedbugs/issue7310.go:13:13: error: second argument must be slice or string
fixedbugs/issue7310.go:14:15: error: incompatible types in binary expression

fixedbugs/issue6964.go:10:13: error: invalid type conversion (cannot use type complex128 as type string)

fixedbugs/issue7538a.go:14:9: error: reference to undefined label ‘_’

fixedbugs/issue8311.go:14:9: error: increment or decrement of non-numeric type

fixedbugs/issue8507.go:12:6: error: invalid recursive type ‘T’

fixedbugs/issue9521.go:16:20: error: argument 2 has incompatible type
fixedbugs/issue9521.go:17:20: error: argument 2 has incompatible type (cannot use type float64 as type int)

fixedbugs/issue8385.go:30:19: error: argument 1 has incompatible type (type has no methods)
fixedbugs/issue8385.go:30:14: error: not enough arguments
fixedbugs/issue8385.go:35:9: error: not enough arguments
fixedbugs/issue8385.go:36:9: error: not enough arguments
fixedbugs/issue8385.go:37:10: error: not enough arguments
fixedbugs/issue8385.go:38:10: error: not enough arguments
fixedbugs/issue8385.go:39:10: error: not enough arguments
fixedbugs/issue8385.go:40:10: error: not enough arguments
fixedbugs/issue8385.go:41:13: error: not enough arguments

fixedbugs/issue8438.go:13:23: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:14:22: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:15:23: error: incompatible type for element 1 in composite literal

fixedbugs/issue8440.go:10:9: error: reference to undefined name ‘n’

Change-Id: I5707aec7d3c9178c4f4d794d4827fc907b52efb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/278032
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

[dev.typeparams] cmd/compile/internal/gc: provide types2 selection info to noder

Change-Id: I231e3a1c9f663e2a63c0ad73d571c7a00005f50b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278092
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

[dev.regabi] cmd/compile: intercept the making of OADDR nodes

This is a mechanical change to intercept the construction of
all OADDR nodes. We will use the new nodAddr and nodAddrAt
functions to compute the Addrtaken bit.

Change-Id: I90ee3acb8e32540a198a9999284573418729f422
Reviewed-on: https://go-review.googlesource.com/c/go/+/275694
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>

cmd/link: do not mark resource section as writable

Resources are immutable, and all other linkers set this section to be
read-only and not read-write. Fix this oversight by removing the writable
flag.

Change-Id: Ib441bde6620be2000f1685df1ea7bfaebdbe7860
Reviewed-on: https://go-review.googlesource.com/c/go/+/268258
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>

cmd/link: deal with ADDR32NB relocations the same way as ADDR32 on arm

As far as I can tell, the addend is the same for both of these, and in
this context we don't really care about setting or unsetting the thumb
selection bit, so just treat these the same way.

Change-Id: I3756c027239f77778c32b317733df9ac92272580
Reviewed-on: https://go-review.googlesource.com/c/go/+/268238
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>

cmd/link: recognize arm header of PE objects

The linker recognizes headers for 386 and amd64 PE objects, but not arm
objects. This is easily overlooked, since its the same as the 386 header
value, except the two nibbles of the first word are swapped. This commit
simply adds the check for this. Without it, .syso objects are rejected,
which means Windows binaries can't have resources built into them. At
the same time, we add comments to better indicate which condition
applies to which arch.

Change-Id: I210411d978504c1a9540e23abc5a180e24f159ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/268237
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>

go/types: import instance.expand and subst.go from dev.go2go

Changes from dev.go2go:
 + A potentially latent bug is fixed when nilling out tparams in an
   instantiated signature (the resulting type could be Typ[Invalid])
 + Support for pointer designation is removed
 + instantiatedHash is updated to use '[]' rather than '()'
 + Several TODOs were added for me to follow-up on, rather than address
   in this CL
 + Error callsites are updated. Deciding on error codes and better error
   messages is punted to a later CL

These changes can be reviewed by comparing with Patchset #1 of this CL.

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

net/http/pprof: don't treat os.Args as format string in Cmdline handler

Found by @josharian running staticcheck against a fork of this code
elsewhere.

Change-Id: Ica8bae5df71adde1a71e541dd55b0b81b97b3baf
Reviewed-on: https://go-review.googlesource.com/c/go/+/277992
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>

go/types: report invalid ... in conversions

This is a port of CL 277072 from the dev.typeparams branch.

Fixes #43124

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

io/fs: fix package reference in FS godoc

Reported by Ben on golang-dev
https://groups.google.com/g/golang-dev/c/gsoj5Vv15j0/m/kZxzYUdnAQAJ

Change-Id: Ic2c9600b831592ad54036b816138760b7fbb737a
Reviewed-on: https://go-review.googlesource.com/c/go/+/277377
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

[dev.typeparams] cmd/compile/internal/syntax: export NewName and use it

Most syntax.Nodes are allocated in one place and there didn't
seem a need to provide factory methods - so as a matter of
API design, all nodes are "naked", without any constructors.

However, Name nodes are frequently used/replaced and also
are created as helper nodes in clients (types2). Make an
exception and export NewName.

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

[dev.regabi] cmd/compile: reorg generated array hash loop

The ORANGE structure that is being replaced by this CL was causing
trouble with another CL (CL 275695).

The problem occurs if you typecheck i in the middle of generating the
body of the ORANGE loop. If you typecheck i, it ends up typechecking
its definition, which secretly typechecks the containing ORANGE.  If
you then add other items to the ORANGE body, those items will never
get typechecked, as the ORANGE is already marked as typechecked.

Instead, just steal the loop we use for the equality code. Might as
well use the same pattern in both places.

Change-Id: Idb1ac77881d2cc9da08c7437a652b50d3ee45e2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275713
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>

[dev.typeparams] cmd/compile/internal/types2: fix stray ')' in error

I missed this in the review of CL 277072, but noticed it in CL 277352.

Change-Id: I432e3569eb4a935cee19805225f02c424d54011e
Reviewed-on: https://go-review.googlesource.com/c/go/+/277962
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>

[dev.typeparams] cmd/compile/internal/types2: report error for invalid type expression

This bug was introduced by the change from go/ast to syntax which
represents pointer types as (unary) operations rather than dedicated
StarExpr nodes. Accordingly, this bug does not exist for go/types.
It's still ok to backport the test.

Fixes #43125.

Change-Id: Ic55d913f8afc92862856e1eb7c2861d07fc56cfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/278013
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

[dev.typeparams] cmd/compile/internal/types2: report invalid ... in conversions

This fixes the bug below for types2.

Updates #43124.

Change-Id: Ic1962d41f321d8a08992d8529625bc133e526b0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/278012
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>