]> Cypherpunks repositories - gostls13.git/log
gostls13.git
4 years ago[dev.regabi] all: merge master (c9fb4eb) into dev.regabi
Russ Cox [Tue, 22 Dec 2020 21:54:51 +0000 (16:54 -0500)]
[dev.regabi] all: merge master (c9fb4eb) into dev.regabi

Merge List:

* 2020-12-22 c9fb4eb0a2 cmd/link: handle grouped resource sections
* 2020-12-22 c06a354bcc test: trigger SIGSEGV instead of SIGTRAP in issue11656.go
* 2020-12-22 0aa9b4709a cmd/pack: r command create output file if not exist
* 2020-12-22 4d27c4c223 runtime: correct error handling in several FreeBSD syscall wrappers
* 2020-12-22 9b6147120a cmd/pack: treat compiler's -linkobj output as "compiler object"
* 2020-12-21 bc7e4d9257 syscall: don't generate ptrace on iOS
* 2020-12-21 6cff874c47 runtime/metrics: add Read examples
* 2020-12-21 8438a5779b runtime: use _exit on darwin
* 2020-12-21 cb95819cf6 runtime: detect netbsd netpoll overrun in sysmon
* 2020-12-21 53c984d976 runtime: skip wakep call in wakeNetPoller on Plan 9
* 2020-12-21 9abbe27710 test: skip issue11656.go on mips/mips64/ppc64

Change-Id: Ibb235fbf6a86ebcf50c686dc11f7c02d1865f845

4 years ago[dev.regabi] codereview.cfg: add config for dev.regabi
Russ Cox [Tue, 22 Dec 2020 20:59:09 +0000 (15:59 -0500)]
[dev.regabi] codereview.cfg: add config for dev.regabi

Change-Id: Ida5cae7475bc19388fa46ceca25d983f560fa4e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/279524
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
4 years agocmd/link: handle grouped resource sections
Jason A. Donenfeld [Sun, 8 Nov 2020 10:57:42 +0000 (11:57 +0100)]
cmd/link: handle grouped resource sections

The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.

However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.

So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.

We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.

Fixes #42866.
Fixes #43182.

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

4 years ago[dev.regabi] cmd/compile: adjust one case in walkexpr
Russ Cox [Tue, 22 Dec 2020 05:07:40 +0000 (00:07 -0500)]
[dev.regabi] cmd/compile: adjust one case in walkexpr

The mid-case n := n.(*ir.AssignExpr) does not lend itself
well to pulling the code into a new function, because n will
be a function argument and will not be redeclarable.

Change-Id: I673f2aa37eea64b083725326ed3fa36447bcc7af
Reviewed-on: https://go-review.googlesource.com/c/go/+/279426
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
4 years ago[dev.regabi] cmd/compile: only access Func method on concrete types
Russ Cox [Mon, 21 Dec 2020 20:10:26 +0000 (15:10 -0500)]
[dev.regabi] cmd/compile: only access Func method on concrete types

Sets up for removing Func from Node interface.
That means that once the Name reorg is done,
which will let us remove Name, Sym, and Val,
Node will be basically a minimal interface.

Passes buildall w/ toolstash -cmp.

Change-Id: I6e87897572debd7f8e29b4f5167763dc2792b408
Reviewed-on: https://go-review.googlesource.com/c/go/+/279484
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
4 years ago[dev.regabi] cmd/compile: separate misc for gc split
Russ Cox [Mon, 21 Dec 2020 06:20:20 +0000 (01:20 -0500)]
[dev.regabi] cmd/compile: separate misc for gc split

Misc cleanup for splitting package gc: API tweaks
and boundary adjustments.

The change in ir.NewBlockStmt makes it a drop-in
replacement for liststmt.

Change-Id: I9455fe8ccae7d71fe8ccf390ac96672389bf4f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/279305
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
4 years ago[dev.regabi] cmd/compile: separate various from Main
Russ Cox [Mon, 21 Dec 2020 07:08:34 +0000 (02:08 -0500)]
[dev.regabi] cmd/compile: separate various from Main

Move various code out of Main itself and into helper functions
that can be moved into other packages as package gc splits up.

Similarly, move order and instrument inside walk to reduce the amount
of API surface needed from the eventual package walk.

Change-Id: I7849258038c6e39625a0385af9c0edd6a3b654a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/279304
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
4 years ago[dev.regabi] cmd/compile: separate typecheck more cleanly
Russ Cox [Mon, 21 Dec 2020 07:22:42 +0000 (02:22 -0500)]
[dev.regabi] cmd/compile: separate typecheck more cleanly

Abstract the typecheck API a bit more so that it is
easier to move into a new package.

Change-Id: Ia0a0146151fa7f6073113e68a2c3f6e42a5d0ad8
Reviewed-on: https://go-review.googlesource.com/c/go/+/279303
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
4 years ago[dev.regabi] cmd/compile: separate dowidth better
Russ Cox [Mon, 21 Dec 2020 06:55:44 +0000 (01:55 -0500)]
[dev.regabi] cmd/compile: separate dowidth better

Having a global MaxWidth lets us avoid needing to
refer to thearch from split-out packages when all
they need is thearch.MAXWIDTH.

And make a couple interface changes to let dowidth
avoid importing package ir directly.
Then it can move into package types.

Change-Id: I2c12e8e22252597530e648848320e19bdd490a01
Reviewed-on: https://go-review.googlesource.com/c/go/+/279302
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
4 years agotest: trigger SIGSEGV instead of SIGTRAP in issue11656.go
Cherry Zhang [Mon, 21 Dec 2020 23:41:16 +0000 (18:41 -0500)]
test: trigger SIGSEGV instead of SIGTRAP in issue11656.go

In issue11656.go, it tests that if the runtime can get a
reasonable traceback when it faults at a non-function PC. It does
it by jumping to an address that contains an illegal or trap
instruction. When it traps, the SIGTRAP crashes the runtime.

This CL changes it to use an instruction that triggers SIGSEGV.
This is due to two reasons:
- currently, the handling of bad PC is done by preparePanic,
  which is only used for a panicking signal (SIGSEGV, SIGBUS,
  SIGFPE), not a fatal signal (e.g. SIGTRAP).
- the test uses defer+recover to get a traceback, which only
  works for panicking signals, not fatal signals.

Ideally, we should handle all kinds of faults (SIGSEGV, SIGBUS,
SIGILL, SIGTRAP, etc.) with a nice traceback. I'll leave this
for the future.

This CL also adds RISCV64 support.

Fixes #43283.

Change-Id: I5e0fbf8530cc89d16e05c3257d282bc1d4d03405
Reviewed-on: https://go-review.googlesource.com/c/go/+/279423
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
4 years agocmd/pack: r command create output file if not exist
Cherry Zhang [Tue, 22 Dec 2020 17:40:32 +0000 (12:40 -0500)]
cmd/pack: r command create output file if not exist

Go 1.15 pack's r command creates the output file if it does not
exist. The system "ar" command does this as well. Do the same.

For bazelbuild/rules_go#2762.

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

4 years ago[dev.regabi] cmd/compile,cmd/link: initial support for ABI wrappers
Than McIntosh [Thu, 24 Sep 2020 17:14:46 +0000 (13:14 -0400)]
[dev.regabi] cmd/compile,cmd/link: initial support for ABI wrappers

Add compiler support for emitting ABI wrappers by creating real IR as
opposed to introducing ABI aliases. At the moment these are "no-op"
wrappers in the sense that they make a simple call (using the existing
ABI) to their target. The assumption here is that once late call
expansion can handle both ABI0 and the "new" ABIInternal (register
version), it can expand the call to do the right thing.

Note that the runtime contains functions that do not strictly follow
the rules of the current Go ABI0; this has been handled in most cases
by treating these as ABIInternal instead (these changes have been made
in previous patches).

Generation of ABI wrappers (as opposed to ABI aliases) is currently
gated by GOEXPERIMENT=regabi -- wrapper generation is on by default if
GOEXPERIMENT=regabi is set and off otherwise (but can be turned on
using "-gcflags=all=-abiwrap -ldflags=-abiwrap"). Wrapper generation
currently only workd on AMD64; explicitly enabling wrapper for other
architectures (via the command line) is not supported.

Also in this patch are a few other command line options for debugging
(tracing and/or limiting wrapper creation). These will presumably go
away at some point.

Updates #27539, #40724.

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

4 years ago[dev.regabi] cmd/compile: add ir.BasicLit to represent literals
Matthew Dempsky [Fri, 18 Dec 2020 04:17:04 +0000 (20:17 -0800)]
[dev.regabi] cmd/compile: add ir.BasicLit to represent literals

This CL changes so that all literals are represented with a new,
smaller ir.BasicLit type, so that ir.Name is only used to represent
declared constants.

Passes buildall w/ toolstash -cmp.

Change-Id: I4702b8e3fa945617bd05881d7a2be1205f229633
Reviewed-on: https://go-review.googlesource.com/c/go/+/279153
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
4 years ago[dev.regabi] cmd/compile: stop reusing Ntype for OSLICELIT length
Matthew Dempsky [Fri, 18 Dec 2020 02:47:26 +0000 (18:47 -0800)]
[dev.regabi] cmd/compile: stop reusing Ntype for OSLICELIT length

For OSLICELITs, we were reusing the Ntype field after type checking to
hold the length of the OSLICELIT's backing array. However, Ntype is
only meant for nodes that can represent types. Today, this works only
because we currently use Name for all OLITERAL constants (whether
declared or not), whereas we should be able to represent them more
compactly with a dedicated type that doesn't implement Ntype.

Passes buildall w/ toolstash -cmp.

Change-Id: I385f1d787c41b016f507a5bad9489d59ccfde7f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/279152
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
4 years ago[dev.regabi] cmd/compile: change noder.declNames to returns ir.Names
Matthew Dempsky [Sat, 19 Dec 2020 04:49:50 +0000 (20:49 -0800)]
[dev.regabi] cmd/compile: change noder.declNames to returns ir.Names

declNames always returns a slice of *ir.Names, so return that directly
rather than as []ir.Node.

While here, also change iimport to directly create ir.ODCL/ir.OAS
statements, rather than calling variter. Allows eliminating a use of
ir.TypeNode.

Passes buildall w/ toolstash -cmp.

Change-Id: Icb75e993c4957b6050c797ba64ee71cfb7a19644
Reviewed-on: https://go-review.googlesource.com/c/go/+/279315
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
4 years ago[dev.regabi] runtime/race: adjust test pattern match for ABI wrapper
Than McIntosh [Wed, 16 Dec 2020 18:45:48 +0000 (13:45 -0500)]
[dev.regabi] runtime/race: adjust test pattern match for ABI wrapper

Adjust the pattern matching in one of the race output test to allow
for the possible introduction of an ABI wrapper. Normally for tests
that match traceback output wrappers are not an issue since they
are screened out by Go's traceback mechanism, but in this case the
race runtime is doing the unwinding, so the wrapper may be visible.

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

4 years agoruntime: correct error handling in several FreeBSD syscall wrappers
Nikhil Benesch [Wed, 9 Dec 2020 20:14:59 +0000 (15:14 -0500)]
runtime: correct error handling in several FreeBSD syscall wrappers

The FreeBSD syscall convention uses the carry flag to indicate whether
an error has occured. The sys_umtx_op, thr_new, and pipe2 syscall
wrappers were failing to account for this convention and silently
suppressing errors as a result. This commit corrects these wrappers
by copying the pattern used by the other fallible syscall wrappers.

Note that futexsleep1 must now explicitly ignore the ETIMEDOUT error
from sys_umtx_op. Previously ETIMEDOUT was implicitly ignored because
sys_umtx_op never returned an error.

Fixes #43106.

Change-Id: I9c422b87cf4c6d308003bf42c3b419f785578b5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/276892
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Than McIntosh <thanm@google.com>

4 years agocmd/pack: treat compiler's -linkobj output as "compiler object"
Cherry Zhang [Mon, 21 Dec 2020 19:11:02 +0000 (14:11 -0500)]
cmd/pack: treat compiler's -linkobj output as "compiler object"

Treat the compiler's -linkobj output as "compiler object, which
means "pack c" will "see through" the file and add individual
entry to the new archive, instead of the object as a whole.

This is somewhat peculiar. But Go 1.15's cmd/pack does this,
although seemingly accidental. We just do the same. FWIW, it
does make things more consistent with/without -linkobj flag.

Fixes #43271.

Change-Id: I6b2d99256db7ebf0fa430f85afa7464e334f6bcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/279483
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
4 years ago[dev.regabi] runtime: fix ABI targets in runtime.panic{Index,Slice} shims
Than McIntosh [Mon, 14 Dec 2020 15:03:37 +0000 (10:03 -0500)]
[dev.regabi] runtime: fix ABI targets in runtime.panic{Index,Slice} shims

Fix up the assembly shim routines runtime.panic{Index,Slice} and
friends so that their tail calls target ABIInternal and not ABI0
functions. This is so as to ensure that these calls don't go through
an ABI0->ABIInternal wrapper (which would throw off the machinery in
the called routines designed to detect whether the violation happened
in the runtime).

Note that when the compiler starts emitting real register calls to
these routines, we'll need to rewrite them to update the arg size and
ensure that args are in the correct registers. For example, the
current shim

TEXT runtime·panicIndex<ABIInternal>(SB),NOSPLIT,$0-16
MOVQ AX, x+0(FP)
MOVQ CX, y+8(FP)
JMP runtime·goPanicIndex<ABIInternal>(SB)

will need to change to

TEXT runtime·panicIndex<ABIInternal>(SB),NOSPLIT,$0
// AX already set up properly
MOVQ CX, BX // second argument expected in BX
JMP runtime·goPanicIndex<ABIInternal>(SB)

Change-Id: I48d1b5138fb4d229380ad12735cfaca5c50e6cc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/278755
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>

4 years agosyscall: don't generate ptrace on iOS
Cherry Zhang [Mon, 21 Dec 2020 18:14:41 +0000 (13:14 -0500)]
syscall: don't generate ptrace on iOS

May fix #43302.

Change-Id: I6b7ddf94495c4fa80cf8a50a38eef5f8b2872669
Reviewed-on: https://go-review.googlesource.com/c/go/+/279481
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
4 years ago[dev.regabi] cmd/compile: stop using ONONAME with Name
Matthew Dempsky [Sat, 19 Dec 2020 04:14:45 +0000 (20:14 -0800)]
[dev.regabi] cmd/compile: stop using ONONAME with Name

This CL changes NewDeclNameAt to take an Op argument to set the Op up
front, and updates all callers to provide the appropriate Op. This
allows dropping the Name.SetOp method.

Passes buildall w/ toolstash -cmp.

Change-Id: I20e580f62d3c8a81223d1c162327c11b37bbf3f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/279314
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
4 years ago[dev.regabi] cmd/compile: simplify declaration importing
Matthew Dempsky [Sat, 19 Dec 2020 03:38:13 +0000 (19:38 -0800)]
[dev.regabi] cmd/compile: simplify declaration importing

Rather than creating Names w/ ONONAME earlier and later adding in the
details, this CL changes the import logic to create and add details at
the same time.

Passes buildall w/ toolstash -cmp.

Change-Id: Ifaabade3cef8cd80ddd6644bff79393b934255d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/279313
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>
4 years ago[dev.regabi] cmd/compile: move itabname call out of implements
Matthew Dempsky [Sun, 20 Dec 2020 03:26:06 +0000 (19:26 -0800)]
[dev.regabi] cmd/compile: move itabname call out of implements

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>

4 years agoruntime/metrics: add Read examples
Michael Anthony Knyszek [Mon, 7 Dec 2020 15:11:46 +0000 (15:11 +0000)]
runtime/metrics: add Read examples

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>

4 years agoMerge "[dev.regabi] all: merge master into dev.regabi" into dev.regabi
Gerrit Code Review [Mon, 21 Dec 2020 19:23:41 +0000 (19:23 +0000)]
Merge "[dev.regabi] all: merge master into dev.regabi" into dev.regabi

4 years ago[dev.regabi] cmd/compile: separate nowritebarrierrec from main
Russ Cox [Mon, 21 Dec 2020 06:56:46 +0000 (01:56 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: separate ssa from other phases
Russ Cox [Mon, 21 Dec 2020 06:44:49 +0000 (01:44 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: separate noder more cleanly
Russ Cox [Mon, 21 Dec 2020 06:36:15 +0000 (01:36 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: separate exportsym more cleanly
Russ Cox [Mon, 21 Dec 2020 14:11:12 +0000 (09:11 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: collect global compilation state
Russ Cox [Mon, 21 Dec 2020 06:29:02 +0000 (01:29 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: setup to move Addrconst, Patch into cmd/internal/obj
Russ Cox [Mon, 21 Dec 2020 06:14:36 +0000 (01:14 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - more
Russ Cox [Fri, 18 Dec 2020 16:29:49 +0000 (11:29 -0500)]
[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>
4 years ago[dev.regabi] all: merge master into dev.regabi
Matthew Dempsky [Sun, 20 Dec 2020 18:36:21 +0000 (10:36 -0800)]
[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

4 years agoruntime: use _exit on darwin
Cherry Zhang [Thu, 12 Nov 2020 02:27:56 +0000 (21:27 -0500)]
runtime: use _exit on darwin

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>
4 years agoruntime: detect netbsd netpoll overrun in sysmon
Michael Pratt [Fri, 11 Dec 2020 19:14:30 +0000 (14:14 -0500)]
runtime: detect netbsd netpoll overrun in sysmon

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>

4 years agoruntime: skip wakep call in wakeNetPoller on Plan 9
Richard Miller [Sat, 5 Dec 2020 19:53:08 +0000 (19:53 +0000)]
runtime: skip wakep call in wakeNetPoller on Plan 9

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>

4 years agotest: skip issue11656.go on mips/mips64/ppc64
Ian Lance Taylor [Sat, 19 Dec 2020 21:46:49 +0000 (13:46 -0800)]
test: skip issue11656.go on mips/mips64/ppc64

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>
4 years agocmd/compile: recognize reassignments involving receives
Matthew Dempsky [Sun, 20 Dec 2020 09:15:46 +0000 (01:15 -0800)]
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>

4 years agotest: for issue11656 try to execute trap, not call it
Ian Lance Taylor [Wed, 16 Dec 2020 04:24:33 +0000 (20:24 -0800)]
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>
4 years agotest: permit "exponent too large" error
Ian Lance Taylor [Fri, 18 Dec 2020 21:54:27 +0000 (13:54 -0800)]
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>
4 years agogo/build: make TestDependencies work again
Ian Lance Taylor [Thu, 17 Dec 2020 22:59:45 +0000 (14:59 -0800)]
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>
4 years agoos: remove dependency on strings package
Ian Lance Taylor [Thu, 17 Dec 2020 22:57:20 +0000 (14:57 -0800)]
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>
4 years ago[dev.regabi] cmd/compile: remove prealloc map
Russ Cox [Thu, 17 Dec 2020 13:49:22 +0000 (08:49 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: remove uses of Name.Offset, Name.copy
Russ Cox [Thu, 17 Dec 2020 07:56:26 +0000 (02:56 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: add ONAMEOFFSET, delete to-be-deleted fields
Russ Cox [Thu, 17 Dec 2020 05:59:35 +0000 (00:59 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - sinit
Russ Cox [Thu, 10 Dec 2020 23:47:09 +0000 (18:47 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - walk
Russ Cox [Thu, 10 Dec 2020 23:45:14 +0000 (18:45 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: rename ir.Find to ir.Any and update uses
Russ Cox [Wed, 16 Dec 2020 15:53:20 +0000 (10:53 -0500)]
[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>
4 years agoos/signal: fix flaky tests for NotifyContext.
Henrique Vicente [Mon, 16 Nov 2020 02:09:31 +0000 (03:09 +0100)]
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>

4 years agocmd/link: avoid use of -T when linking with lld
Than McIntosh [Mon, 14 Dec 2020 18:03:06 +0000 (13:03 -0500)]
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>
4 years agotest: recognize and use gc build tag
Ian Lance Taylor [Thu, 17 Dec 2020 22:03:07 +0000 (14:03 -0800)]
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>
4 years agoapi/go1.16: remove crypto/tls APIs that are moved to Go 1.17
Dmitri Shuralyov [Thu, 17 Dec 2020 20:17:14 +0000 (15:17 -0500)]
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>
4 years agocrypto/tls: revert "add HandshakeContext method to Conn"
Johan Brandhorst [Thu, 12 Nov 2020 20:34:51 +0000 (20:34 +0000)]
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>

4 years agoapi: promote next to go1.16 go1.16beta1
Dmitri Shuralyov [Wed, 9 Dec 2020 03:54:44 +0000 (22:54 -0500)]
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>
4 years ago[dev.regabi] cmd/compile: remove OSELRECV
Cuong Manh Le [Mon, 7 Dec 2020 03:51:44 +0000 (10:51 +0700)]
[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>
4 years ago[dev.regabi] cmd/compile: use OSELRECV2 for all <-c variants
Cuong Manh Le [Sun, 6 Dec 2020 20:24:04 +0000 (03:24 +0700)]
[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>
4 years ago[dev.regabi] cmd/compile: add type assertion in regabi test
Russ Cox [Mon, 14 Dec 2020 18:20:06 +0000 (13:20 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - mop-up
Russ Cox [Thu, 10 Dec 2020 23:48:33 +0000 (18:48 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - noder
Russ Cox [Thu, 10 Dec 2020 23:48:18 +0000 (18:48 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - subr
Russ Cox [Thu, 10 Dec 2020 23:47:58 +0000 (18:47 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - range, select, swt
Russ Cox [Thu, 10 Dec 2020 23:47:32 +0000 (18:47 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - const
Russ Cox [Thu, 10 Dec 2020 23:46:56 +0000 (18:46 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - inl
Russ Cox [Thu, 10 Dec 2020 23:46:45 +0000 (18:46 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - import/export
Russ Cox [Thu, 10 Dec 2020 23:46:29 +0000 (18:46 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - escape
Russ Cox [Thu, 10 Dec 2020 23:46:13 +0000 (18:46 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - ssa
Russ Cox [Thu, 10 Dec 2020 23:45:58 +0000 (18:45 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - order
Russ Cox [Thu, 10 Dec 2020 23:45:35 +0000 (18:45 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup for concrete types - typecheck
Russ Cox [Thu, 10 Dec 2020 23:42:42 +0000 (18:42 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: simplify ir.Find, replace ir.Inspect with ir.Visit
Russ Cox [Sat, 12 Dec 2020 23:50:21 +0000 (18:50 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: limit Implicit method to nodes where it is defined
Russ Cox [Fri, 11 Dec 2020 21:52:21 +0000 (16:52 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: remove use of Initorder, Offset Node fields for initorder
Russ Cox [Fri, 11 Dec 2020 17:55:14 +0000 (12:55 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: change Nodes to be a slice
Russ Cox [Sat, 12 Dec 2020 02:29:53 +0000 (21:29 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: update ir/fmt for concrete types
Russ Cox [Fri, 11 Dec 2020 01:55:10 +0000 (20:55 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: fix potential closure waste in Order
Russ Cox [Mon, 7 Dec 2020 21:07:38 +0000 (16:07 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: rewrite some generic ir.Nod calls
Russ Cox [Mon, 7 Dec 2020 19:58:26 +0000 (14:58 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup preparing for concrete types, 2
Russ Cox [Mon, 7 Dec 2020 19:56:49 +0000 (14:56 -0500)]
[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>
4 years ago[dev.regabi] cmd/compile: cleanup preparing for concrete types
Russ Cox [Mon, 7 Dec 2020 19:56:03 +0000 (14:56 -0500)]
[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>
4 years agohtml/template: avoid race when escaping updates template
Ian Lance Taylor [Thu, 3 Dec 2020 03:18:46 +0000 (19:18 -0800)]
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>
4 years agogo/types: report error for invalid (but empty) expr switch
Rob Findley [Wed, 16 Dec 2020 22:19:44 +0000 (17:19 -0500)]
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>

4 years agocmd/link: handle large relocation addend on darwin/arm64
Cherry Zhang [Mon, 14 Dec 2020 23:52:13 +0000 (18:52 -0500)]
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>
4 years agocmd/link: pass arch-specific flags to external linker when testing supported flag
Cherry Zhang [Tue, 15 Dec 2020 23:31:21 +0000 (18:31 -0500)]
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>
4 years agocmd/internal/goobj: fix buglet in object file reader
Than McIntosh [Tue, 15 Dec 2020 20:54:25 +0000 (15:54 -0500)]
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>

4 years agodoc/go1.16: add link to reflect.StructTag
Tobias Klauser [Tue, 15 Dec 2020 16:48:38 +0000 (17:48 +0100)]
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>
4 years agonet: close connection in localServer teardown
Meng Zhuo [Sat, 28 Nov 2020 10:09:21 +0000 (18:09 +0800)]
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>
4 years agocmd/link: ignore SEH marking on PE objects
Jason A. Donenfeld [Sun, 8 Nov 2020 02:20:36 +0000 (03:20 +0100)]
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>

4 years agotest: update for gofrontend error message changes
Ian Lance Taylor [Tue, 15 Dec 2020 21:15:07 +0000 (13:15 -0800)]
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>

4 years agodoc/go1.15: mention 1.15.3 cgo restriction on empty structs
Ian Lance Taylor [Sat, 12 Dec 2020 03:10:00 +0000 (19:10 -0800)]
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>
4 years agotest: match gofrontend error messages
Ian Lance Taylor [Tue, 15 Dec 2020 06:27:32 +0000 (22:27 -0800)]
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>
4 years agotest: only require issue11674 errors with gc compiler
Ian Lance Taylor [Tue, 15 Dec 2020 06:03:29 +0000 (22:03 -0800)]
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>
4 years agotest: remove bug429 (duplicates runtime.TestSimpleDeadlock)
Ian Lance Taylor [Tue, 15 Dec 2020 05:20:36 +0000 (21:20 -0800)]
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>
4 years agotest: adjust issue11371 to fit in required precision
Ian Lance Taylor [Tue, 15 Dec 2020 05:56:25 +0000 (21:56 -0800)]
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>
4 years agotest: only check for issue11362 error with gc
Ian Lance Taylor [Tue, 15 Dec 2020 05:43:50 +0000 (21:43 -0800)]
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>
4 years agotest: import file name for issue19028
Ian Lance Taylor [Tue, 15 Dec 2020 03:18:20 +0000 (19:18 -0800)]
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>
4 years agodoc/go1.16: fix path, path/filepath release notes
Tobias Klauser [Tue, 15 Dec 2020 09:41:54 +0000 (10:41 +0100)]
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>
4 years agodoc/go1.16: fix formatting in net, net/http and net/http/httputil sections
Tobias Klauser [Tue, 15 Dec 2020 09:36:10 +0000 (10:36 +0100)]
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>
4 years agotext/template: error on range over send channel
Meng Zhuo [Thu, 10 Dec 2020 01:52:52 +0000 (09:52 +0800)]
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>
4 years ago[dev.regabi] cmd/compile: use ir.Ident for imported identifiers
Matthew Dempsky [Sun, 13 Dec 2020 18:35:20 +0000 (10:35 -0800)]
[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>

4 years ago[dev.regabi] cmd/compile: type check externdcl earlier
Matthew Dempsky [Mon, 14 Dec 2020 07:01:34 +0000 (23:01 -0800)]
[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>
4 years ago[dev.regabi] cmd/compile: fix latent Sym.SetPkgDef issue
Matthew Dempsky [Mon, 14 Dec 2020 04:17:09 +0000 (20:17 -0800)]
[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>
4 years agotest: recognize gofrontend error messages
Ian Lance Taylor [Mon, 14 Dec 2020 21:26:35 +0000 (13:26 -0800)]
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>