The test doesn't really require cgo, but it does require that we know
the right flags to use to run the C compiler, and that is not
necessarily correct if we don't support cgo.

Fixes #31565

Change-Id: I04dc8db26697caa470e91ad712376aa621cf765d
Reviewed-on: https://go-review.googlesource.com/c/go/+/172981
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 4c236b9b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/173117

New versions of clang can generate multiple sections named ".text"
when using vague C++ linkage. This is valid ELF, but would cause the
Go linker to report an error when using internal linking:
    symbol PACKAGEPATH(.text) listed multiple times
Avoid the problem by renaming section symbol names if there is a name
collision.

Change-Id: I41127e95003d5b4554aaf849177b3fe000382c02
Reviewed-on: https://go-review.googlesource.com/c/go/+/172697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 3235f7c0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/172701

Change-Id: I3cb4fb7cacba51bfd611ade918f16c618e2569fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/172159Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e47090ab)
Reviewed-on: https://go-review.googlesource.com/c/go/+/172317Reviewed-by: Andrew Bonventre <andybons@golang.org>

Updates #31468
Fixes #31474

Change-Id: I5c4e61631b8af35bfc14b0cb9bc77feec100e340
Reviewed-on: https://go-review.googlesource.com/c/go/+/172058
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 3ebd9523)
Reviewed-on: https://go-review.googlesource.com/c/go/+/172080

Change-Id: I4d1b5e00ab4480b4c5adeeb4f53ddfdfa3903b71
Reviewed-on: https://go-review.googlesource.com/c/go/+/171838
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates #31293

Change-Id: I3d72f732be7b28059310ea6fc134c3bfac81492d
Reviewed-on: https://go-review.googlesource.com/c/go/+/171578Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit ab2a0803)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171766Reviewed-by: Bryan C. Mills <bcmills@google.com>

Change-Id: Iab946b7c903e3c30addc388900421a7ceb803f1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/171149
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: I09e0c2720ec0a51dc73c24b4550a749448656025
Reviewed-on: https://go-review.googlesource.com/c/go/+/171143Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 6f512c8d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171157Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: I6dd60ea7b8a8756be97503e163c2386af16e4e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/171144Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 973c0312)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171147Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: Ia06f7005f466e55a22c76bf2b47d74ee8eb77dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/171139Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 739a78f2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171145Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: I84c9a8ddbd3101dd478e4a8a4e191863e68c6af6
Reviewed-on: https://go-review.googlesource.com/c/go/+/171140Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 8759b4d3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/171141

Change-Id: I07e4404196886b7754414726f25092cca39861a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/170888
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This fixes two problems missed in CL 164877.

First, p.Internal.BuildInfo is now part of the cache key. This is
important since p.Internal.BuildInfo causes the build action to
synthesize a new source file, which affects the output.

Second, recompileForTest is always called for test
packages. Previously, it was only called when there were internal test
sources, so the fix in CL 164877 did not apply to packages that only
had external tests.

Fixes #30937

Change-Id: Iac2d7e8914f0313f9ab4222299a866f67889eb2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/168200
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit d34548e0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/168717
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The current wasm write barrier implementation incorrectly implements
the "deletion" part of the barrier. It correctly greys the new value
of the pointer, but rather than also greying the old value of the
pointer, it greys the object containing the slot (which, since the old
value was just overwritten, is not going to contain the old value).

This can lead to unmarked, reachable objects.

Often, this is masked by other marking activity, but one specific
sequence that can lead to an unmarked object because of this bug is:

1. Initially, GC is off, object A is reachable from just one pointer
in the heap.

2. GC starts and scans the stack of goroutine G.

3. G copies the pointer to A on to its stack and overwrites the
pointer to A in the heap. (Now A is reachable only from G's stack.)

4. GC finishes while A is still reachable from G's stack.

With a functioning deletion barrier, step 3 causes A to be greyed.
Without a functioning deletion barrier, nothing causes A to be greyed,
so A will be freed even though it's still reachable from G's stack.

This CL fixes the wasm write barrier.

Fixes #30873.

Change-Id: I8a74ee517facd3aa9ad606e5424bcf8f0d78e754
Reviewed-on: https://go-review.googlesource.com/c/go/+/167743
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit d9db9e32)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167745Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I990c451ff24844b39dee2477cec4caa9db2e8ebb
Reviewed-on: https://go-review.googlesource.com/c/go/+/170883Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 5ec938cd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170885Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: Iec5e69b3ea163f42234d3b73696427a7aa8732e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/170884Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e47ced78)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170886Reviewed-by: Andrew Bonventre <andybons@golang.org>

This reverts commit 731ebf4d.

Reason for revert: It's not working for large directories.

Change-Id: Ie0f88e0ed1d36c4ea4f32d2acd4e223bd8229ca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/170882Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>

Getdirentries is implemented with the __getdirentries64 function
in libSystem.dylib. That function works, but it's on Apple's
can't-be-used-in-an-app-store-application list.

Implement Getdirentries using the underlying fdopendir/readdir_r/closedir.
The simulation isn't faithful, and could be slow, but it should handle
common cases.

Don't use Getdirentries in the stdlib, use fdopendir/readdir_r/closedir
instead (via (*os.File).readdirnames).

(Incorporates CL 170837 and CL 170698, which were small fixes to the
original tip CL.)

Fixes #31244

Update #28984

RELNOTE=yes

Change-Id: Ia6b5d003e5bfe43ba54b1e1d9cfa792cc6511717
Reviewed-on: https://go-review.googlesource.com/c/go/+/168479Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 9da6530f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170640
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

It's broken on our builders (once we enabled dev mode on our Macs,
see CL 170339)

Updates #31188

Change-Id: Iceea65dc79576057b401a461bfe39254fed1f7ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/170281Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 46c3e217)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170798
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

fd.l.Lock shouldn't be called in a loop.

Manual backport of CL 165598. It could not be cherry-picked due to conflicts.

Fixes #31211

Change-Id: Ib76e679f6a276b32fe9c1594b7e9a506017a7967
Reviewed-on: https://go-review.googlesource.com/c/go/+/170680
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

CL 135377 introduces pass strings and slices to convT2{E,I} by value.
Before that CL, all types, except interface will be allocated temporary
address. The CL changes the logic that only constant and type which
needs address (determine by convFuncName) will be allocated.

It fails to cover the case where type is static composite literal.
Adding condition to check that case fixes the issue.

Also, static composite literal node implies constant type, so consttype
checking can be removed.

Fixes #31209

Change-Id: Ifc750a029fb4889c2d06e73e44bf85e6ef4ce881
Reviewed-on: https://go-review.googlesource.com/c/go/+/168858
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit d47db6dc)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170437
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

In CL 120215 the cgo resolver was changed to have different logic based
on the network being queried. However, the singleflight cache key wasn't
updated to also include the network. This way it was possible for
concurrent queries to return the result for the wrong network.

This CL changes the key to include both network and host, fixing the
problem.

Fixes #31062

Change-Id: I8b41b0ce1d9a02d18876c43e347654312eba22fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/166037Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e341bae0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170320
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

It is possible that a "volatile" value (one that can be clobbered
by preparing args of a call) to be used in multiple write barrier
calls. We used to copy the volatile value right before each call.
But this doesn't work if the value is used the second time, after
the first call where it is already clobbered. Copy it before
emitting any call.

Updates #30977.
Fixes #30996.

Change-Id: Iedcc91ad848d5ded547bf37a8359c125d32e994c
Reviewed-on: https://go-review.googlesource.com/c/go/+/168677
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit f23c601b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/168817
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

A regression was introduced in CL 137335 (5440bfc2) that caused FlushInterval
to not be honored until the first Write() call was encountered. This change
starts the flush timer as part of setting up the maxLatencyWriter.

Fixes #31144

Change-Id: I75325bd926652922219bd1457b2b00ac6d0d41b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/170066Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 2cc34738)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170137

This change is a re-apply of the reverted CL 140863 with changes to
address issue #30821. Specifically, path.Split continues to be used
to split the '/'-separated import path, rather than filepath.Split.

Document the algorithm for how the default executable name is determined
in DefaultExecName.

Rename a variable returned from os.Stat from bs to fi for consistency.

CL 140863 factored out the logic to determine the default executable
name from the Package.load method into a DefaultExecName function,
and started using it in more places to avoid having to re-implement
the logic everywhere it's needed. Most previous callers already computed
the default executable name based on the import path. The load.Package
method, before CL 140863, was the exception, in that it used the p.Dir
value in GOPATH mode instead. There was a NOTE(rsc) comment that it
should be equivalent to use import path, but it was too late in Go 1.11
cycle to risk implementing that change.

This is part 1, a more conservative change for backporting to Go 1.12.2,
and it keeps the original behavior of splitting on p.Dir in GOPATH mode.
Part 2 will address the NOTE(rsc) comment and modify behavior in
Package.load to always use DefaultExecName which splits the import path
rather than directory. It is intended to be included in Go 1.13.

Updates #27283
Updates #26869
Updates #30821
Fixes #30266

Change-Id: Ib1ebb95acba7c85c24e3a55c40cdf48405af34f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/167503Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
(cherry picked from commit 94563de8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/168958
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Google's 8.8.8.8 DNS server used to reports its reverse DNS name
as ending in ".google.com". Now it's "dns.google.".

Change-Id: I7dd15f03239e5c3f202e471618ab867690cb4f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/169679
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 3089d189)
Reviewed-on: https://go-review.googlesource.com/c/go/+/169717

When generating DWARF inline info records, the post-SSA code looks
through the original "pre-inline" dcl list for the function so as to
handle situations where formal params are promoted or optimized away.
This code was not properly handling the case where an output parameter
was promoted to the heap -- in this case the param node is converted
in place from class PPARAMOUT to class PAUTOHEAP. This caused
inconsistencies later on, since the variable entry in the abstract
subprogram DIE wound up as a local and not an output parameter.

Updates #30908.
Fixes #31028.

Change-Id: Ia70b89f0cf7f9b16246d95df17ad6e307228b8c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/168818Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 68a98d52)
Reviewed-on: https://go-review.googlesource.com/c/go/+/169417
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

While many other call sites have been moved to using the proper
higher-level system loading, these areas were left out. This prevents
DLL directory injection attacks. This includes both the runtime load
calls (using LoadLibrary prior) and the implicitly linked ones via
cgo_import_dynamic, which we move to our LoadLibraryEx. The goal is to
only loosely load kernel32.dll and strictly load all others.

Meanwhile we make sure that we never fallback to insecure loading on
older or unpatched systems.

This is CVE-2019-9634.

Fixes #30666
Updates #14959
Updates #28978
Updates #30642

Change-Id: I401a13ed8db248ab1bb5039bf2d31915cac72b93
Reviewed-on: https://go-review.googlesource.com/c/go/+/165798
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
(cherry picked from commit 9b6e9f0c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/168339Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

Fixes #30859
Updates #30491

Change-Id: If4070e5d39d8649643d7e90f6f3eb499642e25ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/164720
Run-TryBot: Baokun Lee <nototon@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
(cherry picked from commit d039e12b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167739
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Baokun Lee <nototon@gmail.com>

Change-Id: I0d4a55af0bee754ab1ee817780027e9f72475afb
Reviewed-on: https://go-review.googlesource.com/c/go/+/167712Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: Id5f76204b8cd3fe67c21c5adfd3a4e456a8cad14
Reviewed-on: https://go-review.googlesource.com/c/go/+/167704
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

Change-Id: I6d3a615c5f72e9aa29d23e127af98d6e836da173
Reviewed-on: https://go-review.googlesource.com/c/go/+/167699Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit f832a97e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167702Reviewed-by: Andrew Bonventre <andybons@golang.org>

Change-Id: I99832fa4f2c3ec28e2dad46cf7607f3766948031
Reviewed-on: https://go-review.googlesource.com/c/go/+/167698Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit d3bb45d9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167701

This reverts commit 746edd45 (CL 167384).

Reason for revert: Dmitri identified a potential problem in https://go-review.googlesource.com/c/go/+/140863/11#message-db0ff6bb2c7b06161ca47de771c4465afa8b1102, and we'd like more time to investigate without holding up the 1.12 release branch.

Updates #27283
Updates #30266
Updates #30821

Change-Id: I49d7bbbe200e80b81899c3bcbf7844717af010aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/167617Reviewed-by: Andrew Bonventre <andybons@golang.org>

Fixes #30816
Updates #30646

Change-Id: I5b7e986b0588e87b9781cce01445e3c55c06b6fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/165897
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit a6436a56)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167497
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

`go build` has chosen the last element of the package import path
as the default output name when -o option is given. That caused
the output of a package build when the module root is the major
version component such as 'v2'.

A similar issue involving `go install` was fixed in
https://golang.org/cl/128900. This CL refactors the logic added
with the change and makes it available as
internal/load.DefaultExecName.

This CL makes 'go test' to choose the right default test binary
name when the tested package is in the module root. (E.g.,
instead of v2.test, choose pkg.test for the test of 'path/pkg/v2')

Fixes #27283
Fixes #30266

Change-Id: I6905754f0906db46e3ce069552715f45356913ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/140863Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit bf94fc3a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167384
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Trying to call a method on a nil interface is a panic in Go. For
example:

	var stringer fmt.Stringer
	println(stringer.String()) // nil pointer dereference

In https://golang.org/cl/143097 we started recovering panics encountered
during function and method calls. However, we didn't handle this case,
as text/template panics before evalCall is ever run.

In particular, reflect's MethodByName will panic if the receiver is of
interface kind and nil:

	panic: reflect: Method on nil interface value

Simply add a check for that edge case, and have Template.Execute return
a helpful error. Note that Execute shouldn't just error if the interface
contains a typed nil, since we're able to find a method to call in that
case.

Finally, add regression tests for both the nil and typed nil interface
cases.

Fixes #30464.

Change-Id: Iffb21b40e14ba5fea0fcdd179cd80d1f23cabbab
Reviewed-on: https://go-review.googlesource.com/c/161761
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
(cherry picked from commit 15b4c71a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164457Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Currently, runtime.KeepAlive applied on a stack object doesn't
actually keeps the stack object alive, and the heap object
referenced from it could be collected. This is because the
address of the stack object is rematerializeable, and we just
ignored KeepAlive on rematerializeable values. This CL fixes it.

Updates #30476.
Fixes #30478.

Change-Id: Ic1f75ee54ed94ea79bd46a8ddcd9e81d01556d1d
Reviewed-on: https://go-review.googlesource.com/c/164537
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 40df9cc6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164627

Instead of trying to guess type of constants in the AST,
which is hard, use the "var cgo%d Type = Constant"
so that typechecking is left to the Go compiler.

The previous code could still fail in some cases
for constants imported from other modules
or defined in other, non-cgo files.

Fixes #30527

Change-Id: I2120cd90e90a74b9d765eeec53f6a3d2cfc1b642
Reviewed-on: https://go-review.googlesource.com/c/go/+/164897
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 711ea1e7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/165748
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Previously, the result of sorting a map[interface{}] containing
multiple concrete types was non-deterministic. To ensure consistent
results, sort first by type name, then by concrete value.

Fixes #30484

Change-Id: I10fd4b6a74eefbc87136853af6b2e689bc76ae9d
GitHub-Last-Rev: 1b07f0c275716e1b2834f74f9c67f897bae82882
GitHub-Pull-Request: golang/go#30406
Reviewed-on: https://go-review.googlesource.com/c/163745Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 9d40fadb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164617
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>