It's not a predeclared type, but a type defined in "unsafe" package.
Fixes#44830
Change-Id: If39815b1070059b608be8231dfac9b7f3307cb15
Reviewed-on: https://go-review.googlesource.com/c/go/+/313349
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: Matthew Dempsky <mdempsky@google.com>
Android seems to block the accept syscall in newer versions. Use accept4
instead on kernel versions that support it (Linux 2.6.28 and newer) and
fall back to accept on ENOSYS.
Fixes#45767
Change-Id: If190ace0e0213207fdaf6eeb79a5543ef18456de
Reviewed-on: https://go-review.googlesource.com/c/go/+/313769
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Within clovar, n.Defn can also be *ir.TypeSwitchGuard. The proper fix
here would be to populate m.Defn and have it filled in too, but we
already leave it nil in inlvar. So for consistency, this CL does the
same in clovar too.
Eventually inl.go should be rewritten to fully respect IR invariants.
Fixes#45743.
Change-Id: I8b38e5d8b2329ad242de97670f2141f713954d28
Reviewed-on: https://go-review.googlesource.com/c/go/+/313289
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The (*loadPkg).mod field normally indicates the module from which the
package was loaded. However, if the package was missing, we previously
used the mod field to instead store the module from which we intend to
load the package next time around.
That sort of dual use makes the semantics (and synchronization) of the
mod field much more complex to reason about. For example, it would be
nice to have the invariant that the mod field is always one of the
modules in the overall build list, or one of the modules selected in
the overall module graph. Similarly, it would be nice to have the
invariant that the version indicated by the mod field can coexist with
(without upgrading) all of the other versions indicated in the mod
fields of other packages.
This repurposing of the mod field appears to be solely in the service
of storing the module when resolving missing imports. To keep
conceptually-separate fields separate, I have changed
resolveMissingImports to store a slice of package–module pairs,
instead of just packages that need to be revisited.
This may increase allocation pressure slightly if we have many
unresolved packages, but most packages are not unresolved, and it
seems worth the cost to use a little extra memory if it means we can
reason more clearly about the (quite complex) behaviors of the module
loader.
For #36460
Change-Id: Ic434df0f38185c6e9e892c5e9ba9ff53b3efe01f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312930
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Change-Id: I50645af74883e2d5dfcd67a5e8c739222c6f645b
Reviewed-on: https://go-review.googlesource.com/c/go/+/313250
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently there's a minor bug where the constant for the min fraction of
time spent scavenging is rounded down to zero. I don't think this
affects anything in practice because this case is exceedingly rare and
extreme, but currently it doesn't properly prevent the pacing parameters
from getting out of hand in these extreme cases.
Fixes#44036.
Change-Id: I7de644ab0ecac33765c337a736482a0966882780
Reviewed-on: https://go-review.googlesource.com/c/go/+/313249
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Also include SWIG C++ files in cgo hash.
For #28749Fixes#37098
Change-Id: I6d912db2788200c2abdf328e382d4fbefda0a9ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/313131
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This CL provide abilty to randomly select P to steal object from its
shared queue. In order to provide such ability randomOrder structure
was copied from runtime/proc.go.
It should reduce contention in firsts Ps and improve balance of object
stealing across all Ps. Also, the patch provides new benchmark
PoolStarvation which force Ps to steal objects.
Benchmarks:
name old time/op new time/op delta
Pool-8 2.16ns ±14% 2.14ns ±16% ~ (p=0.425 n=10+10)
PoolOverflow-8 489ns ± 0% 489ns ± 0% ~ (p=0.719 n=9+10)
PoolStarvation-8 7.00µs ± 4% 6.59µs ± 2% -5.86% (p=0.000 n=10+10)
PoolSTW-8 15.1µs ± 1% 15.2µs ± 1% +0.99% (p=0.001 n=10+10)
PoolExpensiveNew-8 1.25ms ±10% 1.31ms ± 9% ~ (p=0.143 n=10+10)
[Geo mean] 2.68µs 2.68µs -0.28%
name old p50-ns/STW new p50-ns/STW delta
PoolSTW-8 15.0k ± 1% 15.1k ± 1% +0.92% (p=0.000 n=10+10)
name old p95-ns/STW new p95-ns/STW delta
PoolSTW-8 16.2k ± 3% 16.4k ± 2% ~ (p=0.143 n=10+10)
name old GCs/op new GCs/op delta
PoolExpensiveNew-8 0.29 ± 2% 0.30 ± 1% +2.84% (p=0.000 n=8+10)
name old New/op new New/op delta
PoolExpensiveNew-8 8.07 ±11% 8.49 ±10% ~ (p=0.123 n=10+10)
Change-Id: I3ca1d0bf1f358b1148c58e64740fb2d5bfc0bc02
Reviewed-on: https://go-review.googlesource.com/c/go/+/303949
Reviewed-by: David Chase <drchase@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Do it on OpenBSD as well, as OpenBSD and Darwin share code
generator.
Change-Id: I408120795f7fc826637c867394248f8f373906bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/313230
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>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
With the new register ABI, the compiler sometimes introduces spills of
argument registers in function prologs; depending on the positions
assigned to these spills and whether they have the IsStmt flag set,
this can degrade the debugging experience. For example, in this
function from one of the Delve regression tests:
L13: func foo((eface interface{}) {
L14: if eface != nil {
L15: n++
L16: }
L17 }
we wind up with a prolog containing two spill instructions, the first
with line 14, the second with line 13. The end result for the user
is that if you set a breakpoint in foo and run to it, then do "step",
execution will initially stop at L14, then jump "backwards" to L13.
The root of the problem in this case is that an ArgIntReg pseudo-op is
introduced during expand calls, then promoted (due to lowering) to a
first-class statement (IsStmt flag set), which in turn causes
downstream handling to propagate its position to the first of the register
spills in the prolog.
To help improve things, this patch changes the rewriter to avoid
moving an "IsStmt" flag from a deleted/replaced instruction to an
Arg{Int,Float}Reg value, and adds Arg{Int,Float}Reg to the list of
opcodes not suitable for selection as statement boundaries, and
suppresses generation of additional register spills in defframe() when
optimization is disabled (since in that case things will get spilled
in any case).
This is not a comprehensive/complete fix; there are still cases where
we get less-than-ideal source position markers (ex: issue 45680).
Updates #40724.
Change-Id: Ica8bba4940b2291bef6b5d95ff0cfd84412a2d40
Reviewed-on: https://go-review.googlesource.com/c/go/+/312989
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently this test attempts to trigger a concurrent GC in a very
indirect way, but the way it does so is extremely error-prone. This test
is virtually always prone to flaking based on test order. For example if
the test that executed immediately before this one made a big heap but
didn't clean it up, then this test could easily fail to trigger a GC.
I was able to prove this with a small reproducer.
This roundabout way of triggering a GC is also way overkill for this
test. It just wants to get goroutines in a select and shrink their
stacks. Every GC will schedule a stack for shrinking if it can.
Replace all the complicated machinery with a single runtime.GC call.
I've confirmed that the test consistently triggers a stack shrink,
noting that both shrinkstack's copystack call is made and that
syncadjustsudogs (the relevant function that's being indirectly tested)
are both called.
Fixes#44610.
Change-Id: Ib1c091e0d1475bf6c596f56dc9b85eaea366fc73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
At least in mingw-clang it is not permitted to just name a .dll
on the command line. You must name the corresponding import
library instead, even though the dll is used when the executable
is run.
This fixes misc/cgo/testso and misc/cgo/testsovar on windows/arm64.
Change-Id: I516b6ccba2fe3a9ee2c01e710a71850c4df8522f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312046
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(It doesn't work and isn't used by default.)
Change-Id: I90118d889bd963471f0915d8183502b55bd9dbf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/312045
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes the previously failing TestStdcallAndCDeclCallbacks
for the 9+ argument case.
The last time this code passed, the invisible frame pointer
below SP was apparently not enabled on windows/arm64.
Change-Id: Ifc3064e894b2f39d6410f3be51c17309ebab08a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/312042
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This code is needed for use with cgo proper
(as opposed to hand-written DLL calls, which
we always use but only exercise cgo execution,
not cgo linking).
Change-Id: Iddc31d9c1c924d83d032b80dca65ddfda6624046
Reviewed-on: https://go-review.googlesource.com/c/go/+/312041
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Even if not presented with a valid symbol, recover gracefully,
so that debug prints do not crash.
Change-Id: I06bbe4bec5f90b79b4830e772a7fc3d7c919df1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/312036
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
llvm-mingw's lld produces an invalid windows/arm64 executable
when presented with relocations that are out of order
(the relocation for each function is emitted for two different
locations, so we end up with two sorted streams roughly
interlaced, not one sorted stream).
Sorting should not break other systems, so sort always.
Change-Id: Ic9a95e7145881db5984cbda442f27b0cc24748fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/312033
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The clang-mingw toolchain on windows/arm64 expects
.text to NOT be listed as containing initialized data and
.dwarf* to be listed as containing initialized data.
Neither is true today, resulting in the go .text and .dwarf*
not being merged with the system .text and .dwarf*.
Having multiple .text and .dwarf* sections confuses all
kinds of tools.
Change-Id: I1b9832804c5f5d594bf19e8ee0a5ed31bc1d381d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312032
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
DWARF sections generated by mingw-clang seem to include these
(not often - only one out of many in the binary that I am looking at).
Skipping over them, everything parses correctly.
This makes TestDefaultLinkerDWARF pass on windows/arm64.
Change-Id: Ie4a7daa1423f51cbc8c4aac88b1d27c3b52ee880
Reviewed-on: https://go-review.googlesource.com/c/go/+/312031
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The cmd/link check of the objabi header was a bit lax because
historically the assembler has not included the full version string.
And the assembler didn't do that because it didn't have access to it:
that was buried inside the compiler.
But now that we have cmd/internal/objabi, all the tools have full
access to the expected string, and they can use it, which simplifies
the cmd/link consistency check.
Do that.
Change-Id: I33bd2f9d36c373cc3c32ff02ec6368365088b011
Reviewed-on: https://go-review.googlesource.com/c/go/+/312030
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
An exported Go function like
//export F
func F() {}
gets declared in _cgo_export.h as something like
extern void F(void);
The exact declaration varies by operating system.
In particular, Windows adds __declspec(dllimport).
Clang on Windows/ARM64 rejects code that contains
conflicting declarations for F, like:
extern void F(void);
extern void __declspec(dllimport) F(void);
This means that F must not be declared separately from _cgo_export.h:
any code that wants to refer to F must use #include "_cgo_export.h".
Unfortunately, the cgo prologue itself (the commented code before import "C")
cannot include "_cgo_export.h", because that file is itself produced from the
cgo Go sources and therefore cannot be a dependency of the cgo Go sources.
This CL rewrites misc/cgo/test to avoid redeclaring exported functions.
Most of the time, this is not a significant problem: just move the code
that needs the header into a .c file, perhaps with a wrapper exposed
to the cgo Go sources.
The one case that is potentially problematic is f7665, which is part of
the test for golang.org/issue/7665. That bug report explicitly identified
a bug in referring to the C name for an exported function in the same
Go source file as it was exported function. That is now impossible,
at least on Windows/ARM64, so the test is modified a bit and possibly
does not test what the original bug was. But the original bug should
be long gone: that part of the compiler has been rewritten.
Change-Id: I0d14d9336632f0e5e3db4273d9d32ef2cca0298d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312029
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When ABI wrappers are used, there are cases where in Go code we
need the PC of the defined function instead of the ABI wrapper.
Currently we work around this by define such functions as
ABIInternal, even if they do not actually follow the internal ABI.
This CL introduces internal/abi.FuncPCABIxxx functions as compiler
intrinsics, which return the underlying defined function's entry
PC if the argument is a direct reference of a function of the
expected ABI, and reject it if it is of a different ABI.
As a proof of concept, change runtime.goexit back to ABI0 and use
internal/abi.FuncPCABI0 to retrieve its PC.
Updates #44065.
Change-Id: I02286f0f9d99e6a3090f9e8169dbafc6804a2da6
Reviewed-on: https://go-review.googlesource.com/c/go/+/304232
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>
The previous fix to ensure early evaluation of lvalue-init statements
(CL 312632) added it after we'd already peeled away any array-OINDEX
expressions. But those might have init statements too, so we need to
do this earlier actually and perhaps more than once.
Longer term, lvalue expressions shouldn't have init statements anyway.
But rsc and I both spent a while looking into this earlier in the dev
cycle and couldn't come up with anything reasonable.
Fixes#45706.
Change-Id: I2d19c5ba421b3f019c62eec45774c84cf04b30ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/313011
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
At one point this map checked for infinite loops during package iteration.
The last write to the map was mistakenly removed in CL 251445.
However, looking at the code before that change, the map-based
termination strategy was never quite right to begin with: it checked
whether we had ever added any module for the given package, not
whether we had already added the module being proposed right now. (For
packages within nested modules, we could try adding multiple different
modules for a given package without looping.)
Moreover, the "looping trying to add package" failure message was only
marginally helpful. Users are capable of noticing that an invocation
of the 'go' command is taking too long, and will report a bug for an
infinite loop just as readily as a "looping trying to add package"
error.
We could try to add this tracking back in, but it's no substitute for
a proper proof of convergence, and the code is simpler without it.
Instead I'm going to add a proper proof of convergence — or, barring
that, a more accurate and useful check for failure to converge. In the
meantime, this invariantly-empty map isn't doing anybody any good.
For #36460
Change-Id: I2c111d4b4bf59159af0d7e62d1c0ef4ce0a43a71
Reviewed-on: https://go-review.googlesource.com/c/go/+/312929
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Skip execing for version (most reliable) and attempt to reexec
for env, falling back to the go in GOROOT
Fixes#43981
Change-Id: I17fb84d36036807274eecca3d4f64b3add9b9483
Reviewed-on: https://go-review.googlesource.com/c/go/+/288693
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
It is still a common misconception that math/rand can be used for
security-sensitive work if seeded with crypto/rand
(lazyledger/lazyledger-core#270). It can not.
Change-Id: I8598c352d1750eabeada50be9976ab68cbb42cc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/310350
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
CL 281152 improved ascompatee by removing the call to safeExpr on lhs.
But we forgot that lhs int statements, if any, must be walked prior
saving subexpressions, which cause the bug in #45706.
Fixes#45706
Change-Id: I0064315056ef4ca92ebf3c332c2e3a9bb2b26f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/312632
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: Matthew Dempsky <mdempsky@google.com>
GOSSADIR is a useful compiler flag for debugging.
Removed GO_SSA_PHI_LOC_CUTOFF, it is no longer mentioned in the compiler.
Change-Id: I3600f4c6ded95c9d34b85a6f0da6ba89b17a13ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/312290
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This change adds a metric to track scheduling latencies, defined as the
cumulative amount of time a goroutine spends being runnable before
running again. The metric is an approximations and samples instead of
trying to record every goroutine scheduling latency.
This change was primarily authored by mknyszek@google.com.
Change-Id: Ie0be7e6e7be421572eb2317d3dd8dd6f3d6aa152
Reviewed-on: https://go-review.googlesource.com/c/go/+/308933
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
To bring in the fix for sigchanyzer pass to detect valid usage of
unbuffer channel to builtin make.
Fixes#45043
Change-Id: I60d2ee90f7c111183b33747008903a7df88b76ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/312631
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: Bryan C. Mills <bcmills@google.com>
Currently, when copying definition node of an inlined var, we do not
update var Defn field to point to new copied node. That causes all
inlined vars point to the same Defn, and ir.StaticValue can not find
inlined var in the lhs of its definition.
clovar creates new ONAME node for local variables or params of closure
inside inlined function, by copying most of the old node fields. So the
new Node.Defn is not modified, its lhs still refer to old node
instead of new one.
To fix this, we need to do two things:
- In subst.clovar, set a dummy Defn node for inlvar
- During subst.node, when seeing OAS/OAS2 nodes, after substituting, we
check if any node in lhs has the dummy Defn, then set it to the current
OAS/OAS2 node.
Fixes#45606
Change-Id: Ib517b753a7643756dcd61d36deae60f1a0fc53c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/312630
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: Matthew Dempsky <mdempsky@google.com>
For go statement, the wrapper closure needs to esacpe because it
runs asynchronously. Currently, it is not allowed for closures to
escape in the runtime. We have worked around this in the runtime,
so it doesn't "go" any function with arguments and so doesn't
need wrapping. If it ever does, it is not that we can have the
closure not escape, which may lead to miscompilation. Instead,
make the closure escape (which will fail the compilation). In the
future we may allow go'd closure to escape in the runtime.
Change-Id: I5bbe47b524371d2270c242f6c275013cd52abfc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/312889
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The defer wrapping feature added to the compiler's "order" phase
creates temporaries into which it copies defer arguments. If one of
these temps is large enough that we place it into the defer closure by
address (as opposed to by value), then the temp in question can't be
reused later on in the order phase, nor do we want a VARKILL
annotation for it at the end of the current block scope.
Test written by Cherry.
Updates #40724.
Change-Id: Iec7efd87ec5a3e3d7de41cdcc7f39c093ed1e815
Reviewed-on: https://go-review.googlesource.com/c/go/+/312869
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This is a port of CL 312212, CL 312591 (except check_test.go), and
CL 312790 to types2.
Updates #19367.
Updates #40481.
Change-Id: I58ba0b0dad157baba3f82c909d5eb1268b931be4
Reviewed-on: https://go-review.googlesource.com/c/go/+/312511
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Follow up to CL 312591, which was stumping rfindley and I for a
while. Credit to him for figuring out a repro and explaining the
correct solution.
Change-Id: Ib8578bba05f60fc41d382c34c5266d815441e7a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/312790
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
