Rob Findley [Wed, 4 Aug 2021 14:43:08 +0000 (10:43 -0400)]
[dev.typeparams] go/types: switch the TArgs API to NumTArgs/TArg
As with other go/types APIs, we should not expose the underlying
Named.targs slice.
Change-Id: Iba869298fbd3856022ffe8ec2c3273341598c324
Reviewed-on: https://go-review.googlesource.com/c/go/+/340009
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Robert Griesemer [Wed, 4 Aug 2021 03:43:39 +0000 (20:43 -0700)]
[dev.typeparams] cmd/compile/internal/types2: implement term lists
Prerequisite for clean implementation of type sets
on top of term lists.
Change-Id: Ice87f2f47327aa6b1f3eaad7f9af20ad7c548155
Reviewed-on: https://go-review.googlesource.com/c/go/+/339596
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Keith Randall [Wed, 4 Aug 2021 02:33:01 +0000 (19:33 -0700)]
[dev.typeparams] cmd/compile: put shape types in their own package
Put shape types in the top level package called ".shape".
Name them using the serialization of the shape name, instead of
the .shapeN names.
This allows the linker to deduplicate instantiations across packages.
Not sure that this is entirely correct, as shapes in this package
may reference other packages (e.g. a field of a struct). But it seems
to work for now.
For the added test, when you look at the resulting binary (use the -k
option with run.go) it has only one instantiation of F, and 4 call sites:
Change-Id: I627f7e50210aabe4a10d0e2717d87b75ac82e99b
Reviewed-on: https://go-review.googlesource.com/c/go/+/339595
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Austin Clements [Wed, 4 Aug 2021 12:54:09 +0000 (08:54 -0400)]
[dev.typeparams] runtime: handle d.link carefully when freeing a defer
CL 339396 allowed stack copying on entry to and during freedefer, but
this introduced a subtle bug: if d is heap-allocated, and d.link
points to a stack-allocated defer, stack copying during freedefer can
briefly introduce a stale pointer, which the garbage collector can
discover and panic about. This happens because d has already been
unlinked from the defer chain when freedefer is called, so stack
copying won't update stack pointers in it.
Fix this by making freedefer nosplit again and immediately clearing
d.link.
This should fix the longtest builders, which currently fail on
GOMAXPROCS=2 runtime -cpu=1,2,4 -quick in the TestDeferHeapAndStack
test.
This seems like the simplest fix, but it just deals with the subtlety
rather than eliminating it. Really, every call site of freedefer (of
which there are surprisingly many) has hidden subtlety between
unlinking the defer and calling freedefer. We could consolidate the
subtlety into each call site by requiring that they unlink the defer
and set d.link to nil before calling freedefer. freedefer could check
this condition like it checks that various other fields have already
been zeroed. A more radical option is to replace freedefer with
"popDefer", which would both pop the defer off the link and take care
of freeing it. There would still be a brief moment of subtlety, but it
would be in one place, in popDefer. Annoyingly, *almost* every call to
freedefer just pops the defer from the head of the G's list, but
there's one place when handling open-coded defers where we have to
remove a defer from the middle of the list. I'm inclined to first fix
that subtlety by only expanding open-coded defer records when they're
at the head of the defer list, and then revisit the popDefer idea.
Change-Id: I3130d2542c01a421a5d60e8c31f5379263219627
Reviewed-on: https://go-review.googlesource.com/c/go/+/339730
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Rob Findley [Wed, 4 Aug 2021 01:43:39 +0000 (21:43 -0400)]
[dev.typeparams] go/types: move instance.go contents into named.go (cleanup)
This is a port of CL 338469 to go/types.
Change-Id: I3ee655fa2dc7e789f210c8dec171b3358c4ff132
Reviewed-on: https://go-review.googlesource.com/c/go/+/339677
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Wed, 4 Aug 2021 01:39:53 +0000 (21:39 -0400)]
[dev.typeparams] go/types: print constraint info for type param operands
This is a clean port of CL 338309 to go/types.
Change-Id: Ie2c9e2ea51d6321af8bf149e43cd71b7ac282d13
Reviewed-on: https://go-review.googlesource.com/c/go/+/339676
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
This is a straightforward port of CL 338196 to go/types, minus the
deprecated TypeParam.Bound() method (since it is not needed), plus an
adjustment for methodset.go.
Change-Id: Ie372bfeec245094102a2c3257a43499d75981447
Reviewed-on: https://go-review.googlesource.com/c/go/+/339675
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Wed, 4 Aug 2021 01:10:42 +0000 (21:10 -0400)]
[dev.typeparams] go/types: use type terms to represent unions
This is a straightforward port of CL 338092 to go/types.
Change-Id: I414ec0ad95648c201e85fd2b4f494b1206c658e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/339674
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Wed, 4 Aug 2021 00:36:02 +0000 (20:36 -0400)]
[dev.typeparams] cmd/compile/internal/types2: fix a panic in missingMethod
When static == false, missingMethod incorrectly continues with a nil
Func.
Also remove some unnecessary type names from typeterm_test.go, which was
done in the go/types port.
Change-Id: I21fa637ac82b115563d3601314a470a5a43f9ae0
Reviewed-on: https://go-review.googlesource.com/c/go/+/339672
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Tue, 3 Aug 2021 20:50:35 +0000 (16:50 -0400)]
[dev.typeparams] go/types: implement type terms
This is a port of CL 338049 to go/types. It identical to that CL, except
for eliding unnecessary typenames from the testTerms declaration.
Change-Id: Ieb04d7bbc20063044eb63ea985f75d529f030cd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/339653
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Tue, 3 Aug 2021 20:47:15 +0000 (16:47 -0400)]
[dev.typeparams] go/types: use comparable bit rather than ==() method
This is a port of CL 337354 to go/types, adjusted for the error
reporting API and to reposition a couple error messages in
issue47411.go2 (the go/types position is probably better).
A panic is also fixed in lookup.go when method lookup fails and static
== false. I'll send a fix for types2 in a separate CL.
For #47411
Change-Id: Icc48f03c3958695f581f10e8675c1f32434c424b
Reviewed-on: https://go-review.googlesource.com/c/go/+/339652
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Tue, 3 Aug 2021 20:32:23 +0000 (16:32 -0400)]
[dev.typeparams] go/types: embedded type cannot be a (pointer to) a type parameter
This is a port of CL 337353 to go/types, adjusted for the error API and
to comment out a test for MethodSet.
Some nearby error messages that were using errorf rather than error were
also adjusted.
Fixes #43621
Change-Id: I28c9747e044ec7a2863f6890db69475fb8c29231
Reviewed-on: https://go-review.googlesource.com/c/go/+/339651
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: Ib8dbe03f420d28ada6d5fc7003ab0c82c7e06c41
Reviewed-on: https://go-review.googlesource.com/c/go/+/339650
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 335413 to go/types, adjusted for the parsing API of
go/parser.
Change-Id: Ie6836add7d027aaf5d6d3dae65222b1d15bd7558
Reviewed-on: https://go-review.googlesource.com/c/go/+/339649
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Austin Clements [Tue, 3 Aug 2021 21:03:42 +0000 (17:03 -0400)]
[dev.typeparams] runtime: simplify freedefer
Currently, freedefer manually zeros all the fields in the _defer
because simply assigning _defer{} used to cause a nosplit stack
overflow. freedefer is no longer nosplit, so go back to the simpler,
more robust code.
Change-Id: I881f557bab3b1ee7ab29b68e7fb56d0fe6d35d8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/339669
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop
Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.
This unusual flow control leads to a large number of special cases and
complications all over the tool chain.
This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.
This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.
This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.
This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.
This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.
The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.
This is a retry of CL 337652 because we had to back out its parent.
There are no changes in this version.
Change-Id: I3f54b7fec1d7ccac71cc6cf6835c6a46b7e5fb6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/339397
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
[dev.typeparams] runtime: remove unnecessary split-prevention from defer code
Prior to regabi, the compiler passed defer arguments to the runtime as
untyped values on the stack. This meant a lot of defer-related runtime
functions had to be very careful not to grow the stack or allow
preemption since the stack could not be safely scanned or moved.
However, with regabi, every defer is now simply a func() from the
runtime's perspective, which means we no longer have untyped values on
the stack when we enter defer-related runtime code.
Hence, this CL removes a lot of the now-unnecessary carefulness in the
defer implementation. Specifically, deferreturn no longer needs to be
nosplit because it doesn't copy untyped defer arguments to its
caller's frame (we also update some stale comments in deferreturn).
freedefer no longer needs to be nosplit because it's none of its
callers are deeply nosplit. And newdefer and freedefer no longer need
to switch to the systemstack on their slow paths to avoid stack
growth.
deferprocStack is the only function that still needs to be nosplit,
but that's because the compiler calls it with uninitialized live
pointer slots on the stack (maybe we should change that, but that's a
very different fix).
This is a retry of CL 337651, which was rolled back. This version
disables preemption in newdefer and freedefer while they hold the
current P.
Change-Id: Ibf469addc0b69dc3ba9a3d1a5e0c2804b7b4b244
Reviewed-on: https://go-review.googlesource.com/c/go/+/339396
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Matthew Dempsky [Tue, 3 Aug 2021 06:56:13 +0000 (23:56 -0700)]
[dev.typeparams] cmd/compile: avoid redundant method wrappers in unified IR
Currently, unified IR takes a simple approach of generating method
wrappers for every anonymous type that it sees. This is correct, but
spends a lot of time in code generation and bloats the object files
with duplicate method wrappers that the linker discards.
This CL changes it to distinguish anonymous types that were found in
imported packages vs the local package. The simple win here is that
now we stop emitting wrappers for imported types; but by keeping track
of them and marking them as "have" instead of "need", we can avoid
emitting wrappers for types that appear in both the local package and
imported packages.
This can be improved further, but this is a simple first step that
prevents large protobuf projects from blowing up build cache limits.
Change-Id: Ia65e8981cb1f067eca2bd072b9bbb77c27b95207
Reviewed-on: https://go-review.googlesource.com/c/go/+/339411
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Cherry Mui [Thu, 10 Jun 2021 00:14:15 +0000 (20:14 -0400)]
[dev.typeparams] cmd/compile: make softfloat mode work with register ABI
Previously, softfloat mode does not work with register ABI, mainly
because the compiler doesn't know how to pass floating point
arguments and results. According to the ABI it should be passed in
FP registers, but there isn't any in softfloat mode.
This CL makes it work. When softfloat is used, we define the ABI
as having 0 floating point registers (because there aren't any).
The integer registers are unchanged. So floating point arguments
and results are passed in memory.
Another option is to pass (the bit representation of) floating
point values in integer registers. But this complicates things
because it'd need to reorder integer argument registers.
Change-Id: Ibecbeccb658c10a868fa7f2dcf75138f719cc809
Reviewed-on: https://go-review.googlesource.com/c/go/+/327274
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Matthew Dempsky [Tue, 3 Aug 2021 01:01:46 +0000 (18:01 -0700)]
[dev.typeparams] cmd/compile: fail early on unexpected types2.Invalid
In unified IR, fail right away if we find a types2.Invalid while
writing out the package. This provides a clearer error message for
https://github.com/golang/go/issues/25838#issuecomment-448746670.
Updates #25838.
Change-Id: I6902fdd891fc31bbb832b6fdba00eca301282409
Reviewed-on: https://go-review.googlesource.com/c/go/+/338973
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
- Changed some early returns to asserts (instantiateMethods and Shapify
should never take a shape arg)
- Added suggested change (by Ingo) to use copy() in getInstantiation()
- Clarified that shape types never have methods in Shapify(), removed
some TODO comments.
Change-Id: Ia2164ffe670a777f7797bbb45c7ef5e6e9e15357
Reviewed-on: https://go-review.googlesource.com/c/go/+/338971
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Robert Griesemer [Fri, 30 Jul 2021 05:24:37 +0000 (22:24 -0700)]
[dev.typeparams] cmd/compile/internal/types2: move instance.go contents into named.go (cleanup)
This just moves the code around the instance type into named.go
where it belongs. While at it, also removed some left-over references
to instance types (which are gone). Removed instance.go.
Change-Id: I302a86ca50675b0be54f6138fa47f48f00f9c98f
Reviewed-on: https://go-review.googlesource.com/c/go/+/338469
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Cherry Mui [Thu, 10 Jun 2021 00:01:12 +0000 (20:01 -0400)]
[dev.typeparams] runtime: rewrite softfloat functions to avoid using floats
Currently, most softfloat functions take uint32/64 arguments (for
bit representation of float32/64) and operate on uint32/64. But
there are exeptions where the function take float arguments and
operate on float. So they are only actually softfloat if the
helper functions themselves are translated (by the compiler's
softfloat mode). These are mostly fine (besides being a bit
convoluted). But with register ABIs this inconsistency adds
complexity to the compiler to generate such calls, because it
needs to be called with the right ABI.
Rewrite the functions to operate on uint32/64 directly, using
other helper functions. So they all take uint32/64 arguments and
return uint32/64.
Change-Id: Id9383b74bcbafee44160cc5b58ab245bffbbdfd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/327273
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Keith Randall [Fri, 30 Jul 2021 21:00:27 +0000 (14:00 -0700)]
[dev.typeparams] cmd/compile: make all pointer types have the same shape
Except unsafe.Pointer. It has a different Kind, which makes it trickier.
Change-Id: I12582afb6e591bea35da9e43ac8d141ed19532a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/338749
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Keith Randall [Fri, 30 Jul 2021 16:06:38 +0000 (09:06 -0700)]
[dev.typeparams] cmd/compile: allow types with the same underlying type to have the same shape
First baby step to sharing the underlying implementation among several types.
Change-Id: I6a156176d2b7f0131a87285a03b881ce380c26ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/338610
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop
Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.
This unusual flow control leads to a large number of special cases and
complications all over the tool chain.
This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.
This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.
This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.
This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.
This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.
The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.
Change-Id: Ie9f700cd3fb774f498c9edce363772a868407bf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/337652
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
[dev.typeparams] runtime: remove unnecessary split-prevention from defer code
Prior to regabi, the compiler passed defer arguments to the runtime as
untyped values on the stack. This meant a lot of defer-related runtime
functions had to be very careful not to grow the stack or allow
preemption since the stack could not be safely scanned or moved.
However, with regabi, every defer is now simply a func() from the
runtime's perspective, which means we no longer have untyped values on
the stack when we enter defer-related runtime code.
Hence, this CL removes a lot of the now-unnecessary carefulness in the
defer implementation. Specifically, deferreturn no longer needs to be
nosplit because it doesn't copy untyped defer arguments to its
caller's frame (we also update some stale comments in deferreturn).
freedefer no longer needs to be nosplit because it's none of its
callers are deeply nosplit. And newdefer and freedefer no longer need
to switch to the systemstack on their slow paths to avoid stack
growth.
deferprocStack is the only function that still needs to be nosplit,
but that's because the compiler calls it with uninitialized live
pointer slots on the stack (maybe we should change that, but that's a
very different fix).
Change-Id: I1156ec90bff2613fe4b48b84b375943349ce637d
Reviewed-on: https://go-review.googlesource.com/c/go/+/337651
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
[dev.typeparams] runtime: use func() for deferred functions
Prior to regabi, a deferred function could have any signature, so the
runtime always manipulated them as funcvals. Now, a deferred function
is always func(). Hence, this CL makes the runtime's manipulation of
deferred functions more type-safe by using func() directly instead of
*funcval.
Change-Id: Ib55f38ed49107f74149725c65044e4690761971d
Reviewed-on: https://go-review.googlesource.com/c/go/+/337650
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Rob Findley [Thu, 29 Jul 2021 20:39:49 +0000 (16:39 -0400)]
[dev.typeparams] go/types: backport lazy loading changes from CL 336252
When CL 336252 was created (itself a port of CL 335929), types2
tests revealed that lazy expansion of instances was not behaving
correctly with respect to lazy loading of Named types.
This CL ports the fixes from CL 336252 back to go/types.
Change-Id: Iffc6c84a708449633153b800dfb98ff57402893c
Reviewed-on: https://go-review.googlesource.com/c/go/+/338369
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Dan Scales [Thu, 29 Jul 2021 20:36:36 +0000 (13:36 -0700)]
[dev.typeparams] cmd/compile: remove now-unneeded check for '==' method for comparable type
Comparable type no longer has a special method '=='.
Change-Id: I152f324d83343a66300050479181a6607fb7ca26
Reviewed-on: https://go-review.googlesource.com/c/go/+/338409
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Presumably the "It is safe to call on a nil receiver" comment was
mistakenly copied from TypeParams.Len, which is actually safe to call
on a nil receiver.
Change-Id: Iec5ae32c98dc91ce84a6207b47f2b1e530bdbfe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/338430
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
Matthew Dempsky [Thu, 29 Jul 2021 22:58:13 +0000 (15:58 -0700)]
[dev.typeparams] cmd/compile: switch unified IR from TypeParam.Bound to TypeParam.Constraint
Change-Id: Id68d41f09e78343953167cb1e38fb1ebc41a34d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/338429
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Dan Scales [Thu, 29 Jul 2021 14:27:35 +0000 (07:27 -0700)]
[dev.typeparams] cmd/compile: remove remaining uses of Unshapify
The other uses of Unshapify were really only there to allow for the
dictionary checking code at the beginning of generic functions/methods.
But that will go away as soon as we start combining real shapes. If we
get rid of that code, we can get rid of the unshapify calls elsewhere.
The only tricky part is that getInstantiation now gets targs that may each
either be a shape or concrete type, and it must translate any concrete
types to shapes, while leaving the already existing shapes.
Change-Id: Ib2b9072b921f8e064958548a1078d82f1d040c9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/338289
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Dan Scales [Tue, 27 Jul 2021 02:25:40 +0000 (19:25 -0700)]
[dev.typeparams] cmd/compile: handle meth expressions on typeparams
Rewrite a method expression such as 'T.String' (where T is type param
and String is part of its type bound Stringer) as:
func(rcvr T, other params...) {
return Stringer(rcvr).String(other params...)
}
New function buildClosure2 to create the needed closure. The conversion
Stringer(rcvr) uses the dictionary in the outer function.
For a method expression like 'Test[T].finish' (where finish is a method
of Test[T]), we can already deal with this in buildClosure(). We just
need fix transformDot() to allow the method lookup to fail, since shapes
have no methods on them. That's fine, since for any instantiated
receiver type, we always use the methods on the generic base type.
Also removed the OMETHEXPR case in the main switch of node(), which
isn't needed any (and removes one more potential unshapify).
Also, fixed two small bugs with handling closures that have generic
params or generic captured variables. Need to set the instInfo for the
closure in the subst struct when descending into a closure during
genericSubst() and was missing initializing the startItabConv and gfInfo
fields in the closure info.
Change-Id: I6dadedd1378477936a27c9c544c014cd2083cfb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/338129
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
This matches the accessor named Constraint, and any documentation we have so far.
Use iface instead of Bound internally to types2; keep Bound because of two external
uses but mark it as deprecated. Adjust clients.
Change-Id: Id1a2c2f28259a16082e875eee0534d46cf157336
Reviewed-on: https://go-review.googlesource.com/c/go/+/338196
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Wed, 28 Jul 2021 22:29:19 +0000 (15:29 -0700)]
[dev.typeparams] cmd/compile: set type parameter indices when they are bound
This is a port of CL 336249 with adjustments due to slightly
different handling of type parameter declaration in types2.
The CL also contains adjustments to the compiler front-end.
With this change it is not necessary to export type parameter
indices. Filed issue #47451 so we don't forget.
Change-Id: I2834f7be313fcb4763dff2a9058f1983ee6a81b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/338192
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Introduce new dynamic dottype operations which take a dynamic
instead of static type to convert to.
Change-Id: I5824a1fea056fe811b1226ce059e1e8da1baa335
Reviewed-on: https://go-review.googlesource.com/c/go/+/337609
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Matthew Dempsky [Wed, 28 Jul 2021 20:17:56 +0000 (13:17 -0700)]
[dev.typeparams] cmd/compile: don't export blank functions in unified IR
After the previous two CLs, there's no need for unified IR to
write/read blank functions anymore: types2 has already checked that
they're valid, and the compiler backend is going to ignore them.
Allows dropping code for worrying about blank methods and will
probably simplify some of the object handling code eventually too.
Fixes #47446.
Change-Id: I03cb722793d676a246b1ab768b5cf0d3d2578b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/338096
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
After typechecking a blank function, we can clear out its body and
skip applying middle-end optimizations (inlining, escape analysis). We
already skip sending them through SSA, and the previous CL updated
inlining and escape analysis regress tests to not depend on compiling
blank functions.
Updates #47446.
Change-Id: Ie678763b0e6ff13dd606ce14906b1ccf1bbccaae
Reviewed-on: https://go-review.googlesource.com/c/go/+/338095
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
These tests specifically check that blank functions/methods work.
* interface/fail.go
Not sure the motivation for the blank method here, but it's empty
anyway.
* typeparam/tparam1.go
Type-checking test, but uses "-G" (to use types2 instead of typecheck).
Updates #47446.
Change-Id: I9ec1714f499808768bd0dcd7ae6016fb2b078e5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/338094
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Matthew Dempsky [Wed, 28 Jul 2021 20:39:30 +0000 (13:39 -0700)]
[dev.typeparams] test/typeparam: gofmt -w
We don't usually reformat the test directory, but all of the files in
test/typeparam are syntactically valid. I suspect the misformattings
here are because developers aren't re-installing gofmt with
-tags=typeparams, not intentionally exercising non-standard
formatting.
Change-Id: I3767d480434c19225568f3c7d656dc8589197183
Reviewed-on: https://go-review.googlesource.com/c/go/+/338093
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>
Rob Findley [Wed, 21 Jul 2021 16:12:22 +0000 (12:12 -0400)]
[dev.typeparams] cmd/compile/internal/types2: merge instance and Named to eliminate sanitization
This is a port of CL 335929 to types2. It differs significantly from
that CL to handle lazy loading, which wasn't tested in go/types.
Additionally, the *Checker field was moved out of instance and back
onto Named. This way we can tell whether a Named type is uninstantiated
simply by checking whether Named.instance is non-nil, which simplified
the code considerably.
Fixes #46151
Change-Id: I617263bcfaa768ac5442213cecad8d567c2749fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/336252
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Dan Scales [Mon, 26 Jul 2021 01:27:15 +0000 (18:27 -0700)]
[dev.typeparams] cmd/compile: mark methods of instantiated interface types as used
Fix the cons.go missing method error. Mark all the methods of
instantiated interface types as used. We could try to record all the
exact methods used for generic interface types, but for now, just mark
all the methods as used so that their methods are not dead-code
eliminated.
Change-Id: I35685eda82476244371379b97691a1b8506ef0f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/337349
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Robert Griesemer [Mon, 26 Jul 2021 21:50:57 +0000 (14:50 -0700)]
[dev.typeparams] cmd/compile/internal/types2: use comparable bit rather than ==() method
This removes the special "==" methods from comparable interfaces in
favor of a "comparable" flag in TypeSets indicating that the interface
is or embeds comparable. Fixes various related implementation
inaccuracies.
While at it, fix setup of the predeclared error and comparable
interface types by associating their respective type name objects
with them.
For #47411.
Change-Id: I409f880c8c8f2fe345621401267e4aaabd17124d
Reviewed-on: https://go-review.googlesource.com/c/go/+/337354
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Keith Randall [Tue, 27 Jul 2021 02:37:10 +0000 (19:37 -0700)]
[dev.typeparams] cmd/compile: don't need to unshapify append calls
append is fine using shape types.
Change-Id: Iae829b9b5929d4dc7aa74bed57da13d4f6d746be
Reviewed-on: https://go-review.googlesource.com/c/go/+/337669
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
[dev.typeparams] runtime: don't keep stack uintptr across potential stack move
Currently, deferproc stores the caller SP as a uintptr in a local
variable across a call to newdefer, but newdefer could grow the stack
and invalidate this saved SP, causing deferproc to store a stale SP in
the defer record. This would lead to us later failing to match that
defer to its calling frame, and we wouldn't run the defer at the right
time (or possibly at all).
It turns out this isn't crashing horribly right now only because the
compiler happens to only materialize the result of getcallersp when
this variable is used, *after* the call to newdefer. But this is
clearly on thin ice, so this CL moves the getcallersp() to the place
where we actually need the result.
Change-Id: Iae8ab226e03e4482f16acfb965885f0bd83a13b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/337649
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Robert Griesemer [Mon, 26 Jul 2021 19:13:45 +0000 (12:13 -0700)]
[dev.typeparams] cmd/compile/internal/types2: embedded type cannot be a (pointer to) a type parameter
Change-Id: I5eb03ae349925f0799dd866e207221429bc9fb3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/337353
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Change-Id: I95a96f9dbd199cee3a4be8f42cd64e7f44ba5e5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/336989
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Robert Griesemer [Wed, 21 Jul 2021 23:45:00 +0000 (16:45 -0700)]
[dev.typeparams] cmd/compile/internal/types2: import regexp/syntax instead of cmd/compile/internal/syntax
This is a straight port of https://golang.org/cl/330431.
For #43232
Change-Id: I5954bdff22a524eaa08754947da9b428b27f7d95
Reviewed-on: https://go-review.googlesource.com/c/go/+/336351
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Wed, 21 Jul 2021 23:36:49 +0000 (16:36 -0700)]
[dev.typeparams] cmd/compile/internal/types2: fix a bug in package qualification logic
This is a partial port of https://golang.org/cl/330629, containing
only the actual bug fix and adjustements to another test file.
The respective test case has not been ported yet as it requires
some bigger adjustments.
For #46905
Change-Id: Ibd20658b8a31855da20cf56e24bcce9560656ca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/336350
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Matthew Dempsky [Mon, 26 Jul 2021 19:13:55 +0000 (12:13 -0700)]
[dev.typeparams] all: merge master (ecaa681) into dev.typeparams
Conflicts:
- src/cmd/compile/internal/ssagen/ssa.go
CL 336629 touched code that had already been removed on dev.typeparams.
Merge List:
+ 2021-07-26 ecaa6816bf doc: clarify non-nil zero length slice to array pointer conversion
+ 2021-07-26 1868f8296e crypto/x509: update iOS bundled roots to version 55188.120.1.0.1
+ 2021-07-25 849b791129 spec: use consistent capitalization for rune literal hex constants
+ 2021-07-23 0914646ab9 doc/1.17: fix two dead rfc links
+ 2021-07-22 052da5717e cmd/compile: do not change field offset in ABI analysis
Matthew Dempsky [Fri, 2 Jul 2021 23:59:01 +0000 (16:59 -0700)]
[dev.typeparams] cmd/compile: fix unified IR support for //go:nointerface
This CL changes fixedbugs/issue30862.go into a "runindir" test so that
it can use '-goexperiment fieldtrack' and test that //go:nointerface
works with cmd/compile. In particular, this revealed that -G=3 and
unified IR did not handle it correctly.
This CL also fixes unified IR's support for //go:nointerface and adds
a test that checks that //go:nointerface, promoted methods, and
generics all interact as expected.
Updates #47045.
Change-Id: Ib8acff8ae18bf124520d00c98e8915699cba2abd
Reviewed-on: https://go-review.googlesource.com/c/go/+/332611
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
doc: clarify non-nil zero length slice to array pointer conversion
There is an example for nil slice already, so adding example for non-nil
zero length slice, too, clarifying to the reader that the result is also
non-nil and different from nil slice case.
Updates #395
Change-Id: I019db1b1a1c0c621161ecaaacab5a4d888764b1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/336890
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Keith Randall [Sat, 24 Jul 2021 21:11:27 +0000 (14:11 -0700)]
[dev.typeparams] cmd/compile: fix HasShape, add dottype test
HasShape needs a TINTER case.
Add a test for x.(T) in various situations. Needs the fix above.
Also remove ONEW unshapify case. It is ok for ONEW to have a shape
type, as it will just be passed to mallocgc, or possibly used as a
stack object type, both of which are ok.
Change-Id: Ibddf8f5c8c254d32cb5ebcaca7dc94b4c00ab893
Reviewed-on: https://go-review.googlesource.com/c/go/+/337231
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Dan Scales [Sun, 18 Jul 2021 18:10:41 +0000 (11:10 -0700)]
[dev.typeparams] transformDot() should set Selection and tc flag for added ODOTs
Fixes -G=3 issue with issue44688.go.
Change-Id: Ie98c0cbd48683dedd115332043f14c8f3160f46c
Reviewed-on: https://go-review.googlesource.com/c/go/+/337029
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Dan Scales [Sat, 24 Jul 2021 00:19:51 +0000 (17:19 -0700)]
[dev.typeparams] cmd/compile: get rid of concretify use for bounds.
We just need to substitute from the typeparams to the shapes for the dst
type of the bound.
Removed concretify substituter, not used anymore. Also removed
shape2params, not needed anymore.
However, since the dst type is now not concrete, this gives more cases
where the linker can't find a method.
I realized that we need to call MarkUsedIfaceMethod to mark a method as
used on a particular interface, else a type's method can be still
deadcoded even though MarkTypeUsedInInterface has been called on the
concrete type. I added a new version MarkUsedIfaceMethodIndex to fit my
use case.
Change-Id: Id67b72b350889dd3688b42739c337d5d79a0d1a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/337230
Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Keith Randall [Sat, 24 Jul 2021 01:10:58 +0000 (18:10 -0700)]
[dev.typeparams] cmd/compile: introduce OCONVIDATA op
This operation computes just the data field needed to put its argument
into an interface. Used by generics because we produce the type field
of an interface using dictionaries (instead of statically).
With this operation defined, we can now assert that shape types
are never marked as used in interfaces (the only previous use
was IDATA(CONVIFACE(t))).
Change-Id: Idb1eb5f3b238285cb99413d382599c0621b7681a
Reviewed-on: https://go-review.googlesource.com/c/go/+/337109
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Rob Findley [Fri, 23 Jul 2021 14:00:10 +0000 (10:00 -0400)]
[dev.typeparams] go/types, types2: set tset when constructing interfaces in the universe
As of CL 334894, type sets are lazily evaluated on interfaces. For the
universe interfaces error and comparable, this can lead to data races
when type checking concurrently. Fix this by computing their type set
when they are defined.
Tested using the repro from #47345. I considered checking this in as a
test, but it probably wouldn't add much value going forward.
Fixes #47345
Change-Id: I014a511b8e3c092c86201a8bfc7f5f494f8f20e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/336910
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
Keith Randall [Fri, 23 Jul 2021 22:23:57 +0000 (15:23 -0700)]
[dev.typeparams] cmd/compile: fix some issues with cons.go
Add a test to make sure there's no invalid OCONVIFACEs when stenciling is done.
Use concrete types for the type of DOTTYPE and DOTTYPE2.
MarkTypeUsedInInterface - should we allow types with shape types
underneath? I think the itab CL will help with this (at least, for
a remaining cons.go issue).
Change-Id: I2c96d74e8daaca26cadc84ea94abb9a27c0bb240
Reviewed-on: https://go-review.googlesource.com/c/go/+/337069
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Dan Scales [Fri, 23 Jul 2021 21:38:04 +0000 (14:38 -0700)]
[dev.typeparams] cmd/compile: add CONVIFACE nodes for return values during noder2
Even if we can otherwise transform a return statement because of type
params, add CONVIFACE nodes where appropriate.
Change-Id: Ia2216d5f6805926075ba6802a4385eee1d63e37e
Reviewed-on: https://go-review.googlesource.com/c/go/+/337049
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Dan Scales [Tue, 13 Jul 2021 02:34:15 +0000 (19:34 -0700)]
[dev.typeparams] cmd/compile: add dictionary entries for itab conversion
This fix the case where a type param or derived type is converted to a
non-empty interface. Previously, we were converting to an empty
interface and then using DOTTYPE to convert to the correct non-empty
interface. In that case, we can get the needed itab directly from the
dictionary. This is needed for correctness from shapes, if the
destination interface is parameterized, else we will incorrectly convert
to the shape version of the interface.
Creating/writing an itab can involve generating wrappers for a bunch of
methods, which may use dictionaries. So, all the
dictionaries/instantiations are being generated on the fly and have
recursive relationships, it is simplest to finish creating/writing the
itabs at the end of the stenciling phase. So, we create a list of the
dictionaries which need to be completed by writing out their itab
entries.
The existing tests ordered.go, ifaceconv.go, and issue44688.go make use
of this optimization.
Got itab conversions for bound calls working, except for 13.go.
Also, want to get rid of the concretify, but I think we need more info
on the Bound from types2.
Change-Id: If552958a7b8a435500d6cc42c401572c367b30d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336993
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Dan Scales [Wed, 21 Jul 2021 23:23:17 +0000 (16:23 -0700)]
[dev.typeparams] Add CONVIFACE nodes in noder2, where possible
Changes to add CONVIFACE nodes where possible in noder2, even when the
args are typeparams. The transformation to insert a CONVIFACE node can
usually happen when there an obvious assignment/conversion to an
interface type from a non-interface type. So, we now do this
tranformation for:
- direct conversions to an interface type
- function arguments that are implicitly converted to an interface
based on the parameter types.
- EQ/NE comparison of an interface and a non-interface
With this change, we can remove some special case checks for CONVIFACE
nodes after transformation in node(), and instead just have the one
check in the CONVIFACE check.
Change-Id: I7cf2ef920aebf9e5553210aeaf19f344e128ca62
Reviewed-on: https://go-review.googlesource.com/c/go/+/336992
Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Alberto Donizetti [Fri, 23 Jul 2021 16:45:41 +0000 (18:45 +0200)]
doc/1.17: fix two dead rfc links
Updates #44513
Change-Id: Ia0c6b48bde2719f3a99cb216b6166d82159198d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336930
Trust: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Thu, 22 Jul 2021 22:30:01 +0000 (15:30 -0700)]
[dev.typeparams] cmd/compile/internal/types: format union types
Previously it was just printing <S>. Now it prints things like int32|~int64.
Change-Id: I960b011ce8ed360020a49ae7809d85d1d1fdbfb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/336692
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Cherry Mui [Thu, 22 Jul 2021 16:42:09 +0000 (12:42 -0400)]
cmd/compile: do not change field offset in ABI analysis
Currently, the ABI analysis assigns parameter/result offsets
to the fields of function *Type. In some cases, we may have
an ABI0 function reference and an ABIInternal reference share
the same function *Type. For example, for an ABI0 function F,
"f := F" will make f and (ABI0) F having the same *Type. But f,
as a func value, should use ABIInternal. Analyses on F and f will
collide and cause ICE.
Also, changing field offsets in ABI analysis has to be done very
carefully to avoid data races. It has been causing
trickiness/difficulty.
This CL removes the change of field offsets in ABI analysis
altogether. The analysis result is stored in ABIParamAssignment,
which is the only way to access parameter/result stack offset now.
Fixes #47317.
Fixes #47227.
Change-Id: I23a3e081a6cf327ac66855da222daaa636ed1ead
Reviewed-on: https://go-review.googlesource.com/c/go/+/336629
Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
Matthew Dempsky [Wed, 21 Jul 2021 18:43:57 +0000 (11:43 -0700)]
[dev.typeparams] runtime: mark TestGcSys as flaky
I don't know what this test is doing, but it very frequently flakes
for me while testing mundane compiler CLs. According to the issue log,
it's been flaky for ~3 years.
Updates #37331.
Change-Id: I81c43ad646ee12d4c6561290a54e4bf637695bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/336349
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Ian Lance Taylor [Thu, 22 Jul 2021 02:57:56 +0000 (19:57 -0700)]
runtime: don't clear timerModifiedEarliest if adjustTimers is 0
This avoids a race when a new timerModifiedEarlier timer is created by
a different goroutine.
Fixes #47329
Change-Id: I6f6c87b4a9b5491b201c725c10bc98e23e0ed9d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336432
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Keith Randall [Thu, 22 Jul 2021 02:17:20 +0000 (19:17 -0700)]
[dev.typeparams] cmd/compile: make sure types added to the dictionary are instantiated correctly
Make sure the instantiating types are the type parameters of the containing
function (or types derived from those).
The one exception is the argument of a OFUNCINST, whose type
parameters are those of the declaration site of the function or method
being instantiated. We skip those types.
Change-Id: I4b3ff22eb8a81a76476930cf8ed2a7dd6489d8b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/336352
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Changed the implementation such that the result is a variable rather than
a constant if the argument type (or the struct in case of unsafe.Offsetof)
has a size that depends on type parameters.
Minor unrelated adjustments.
For #40301.
Change-Id: I1e988f1479b95648ad95a455c764ead829d75749
Reviewed-on: https://go-review.googlesource.com/c/go/+/335413
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
[dev.typeparams] cmd/compile: fix missing condition in usemethod
CL 330670 simplified usemethod, but dropped the previous condition to
ensure the function have 1 or 2 result. This CL restore that condition,
and also add a test for it.
Change-Id: I434e3736785b43ceea0b386d8d9d01ad78a4ccd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/336609
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>
Rob Findley [Wed, 21 Jul 2021 15:26:00 +0000 (11:26 -0400)]
[dev.typeparams] go/types: use the TParams API consistently
Even internally to the type checker, we should use the TParams and
RParams methods instead of accessing fields directly, as TParams may be
lazily expanded, and in the future we may want to pack receiver and
function type parameters into a single field on Signature.
We should also not differentiate a nil *TParamList from an empty
*TParamList.
Change-Id: I85c616e6c708a89b6a5eb1e69fe0b014276eda90
Reviewed-on: https://go-review.googlesource.com/c/go/+/336251
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Wed, 21 Jul 2021 14:21:23 +0000 (10:21 -0400)]
[dev.typeparams] go/types: set type parameter indices when they are bound
It is invalid to use a type parameter for more than one type, so we can
avoid passing the type parameter index to NewTypeParam and just set it
when type parameters are bound to a type via SetTParams or during type
checking.
In order to enforce the correctness of this change, introduce a
TypeParams type to represent a list of type parameters that have been
associated with a type. For now, expose this new type as the API for
type parameters, but this is of course not necessarily a final API.
Allowing *TypeParams to be nil also decreases the size of Named and
Signature, which is good as most instances of these types will not be
parameterized.
Change-Id: Ia1e39ba51edb05bb535eb5f41c34e9dd02d39c38
Reviewed-on: https://go-review.googlesource.com/c/go/+/336249
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Matthew Dempsky [Fri, 2 Jul 2021 22:42:20 +0000 (15:42 -0700)]
[dev.typeparams] test: cleanup 'go env' and -goexperiment
This CL makes two related changes:
1. It uses 'go env -json' to query the environment configuration,
rather than attempting to manually reconstruct the values that cmd/go
is going to use.
2. It changes the -goexperiment flag to *extend* any ambient
GOEXPERIMENT configuration. Notably, this means that '-goexperiment
fieldtrack' now tests fieldtracking in conjunction with any other
experiments (e.g., unified IR). Tests that want to test an exact
GOEXPERIMENT config should use '-goexperiment none,foo' instead.
Change-Id: I96a97198209e540e934fe7035110c3ae3a8f0e6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/332610
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
David Chase [Wed, 21 Jul 2021 22:38:05 +0000 (18:38 -0400)]
runtime: move mem profile sampling into m-acquired section
It was not safe to do mcache profiling updates outside the critical
section, but we got lucky because the runtime was not preemptible.
Adding chunked memory clearing (CL 270943) created preemption
opportunities, which led to corruption of runtime data structures.
Fixes #47304.
Fixes #47302.
Change-Id: I461615470d62328a83ccbac537fbdc6dcde81c85
Reviewed-on: https://go-review.googlesource.com/c/go/+/336449
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Rob Findley [Tue, 20 Jul 2021 17:07:50 +0000 (13:07 -0400)]
[dev.typeparams] go/types: trigger verification while resolving instance
The refactoring of CL 335929 to merge the instance and Named types
resulted in type instances only being evaluated once. As a side effect,
we only verified constraints once per unique instantiation expression.
This can be confusing if type instantations are occurring far apart in
the code. Resolve this by lifting up the verification logic into
Instantiate and InstantiateLazy.
Change-Id: Icd5a482d097d983073955c62931441edfd92f5c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/335978
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Mon, 19 Jul 2021 17:11:50 +0000 (13:11 -0400)]
[dev.typeparams] go/types: merge instance and Named to eliminate sanitization
Storing temporary syntactic information using an *instance type forces
us to be careful not to leak references to *instance in the checker
output. This is complex and error prone, as types are written in many
places during type checking.
Instead, temporarily pin the necessary syntactic information directly to
the Named type during the type checking pass. This allows us to avoid
having to sanitize references.
This includes a couple of small, unrelated changes that were made in the
process of debugging:
- eliminate the expandf indirection: it is no longer necessary
- include type parameters when printing objects
For #46151
Change-Id: I767e35b289f2fea512a168997af0f861cd242175
Reviewed-on: https://go-review.googlesource.com/c/go/+/335929
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Dan Scales [Mon, 19 Jul 2021 19:41:30 +0000 (12:41 -0700)]
[dev.typeparams] Fix problem with 14.go
Removed a case in transformCall() where we were setting a type on n,
which isn't needed, since noder2 already set the type of n. More
importantly, we are losing information, since the type of the results
may be a shape type, but the actual type of call is the known type
from types2, which may be a concrete type (in this case Zero[MyInt]).
That concrete type will then be used correctly if the concrete result is
converted to an interface.
If we are inlining the call to Zero[MyInt], we need to add an implicit
CONVNOP operation, since we are going to use the result variable
directly, which has a shape type. So, add an implicit CONVNOP to
remember that the known type is the concrete type.
Also cleaned up 14.go a bit, so it is more understandable. Renamed type
T to AnyInt, since T is used elsewhere as a type parameter. Reformatted
Zero function and added a comment.
Change-Id: Id917a2e054e0bbae9bd302232853fa8741d49b64
Reviewed-on: https://go-review.googlesource.com/c/go/+/336430
Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Dan Scales [Sun, 18 Jul 2021 18:09:12 +0000 (11:09 -0700)]
[dev.typeparams] Get dictionaryCapture.go working.
METHVALUE in a generic function (that is not called) was not causing
buildClosure() to be called and therefore not using dictionaries. Also,
had to add an extra check to make sure that if we have a FUNCINST
node above a METHVALUE, we only call buildClosure once.
Change-Id: I49756152fc343e5ac1c449e697960fc2a0f482ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/336429 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Dan Scales [Wed, 21 Jul 2021 02:18:15 +0000 (19:18 -0700)]
[dev.typeparams] Fix the types of the OFUNCINST nodes in noder2
types2 doesn't actually give us the type of an instantiated
function/method after the type args have been applied. So, do a
substitution at the point that we create the OFUNCINST nodes.
We also needed to add in translation of the typeparams of a function
signature in the type substituter. If the type params of the function
become all concrete after the substitution, then we just drop them,
since the whole signature must now be concrete.
Change-Id: I6116d2aa248be6924ec9e6d8516678db45aa65c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/336370
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Dan Scales [Mon, 19 Jul 2021 05:10:13 +0000 (22:10 -0700)]
[dev.typeparams] cmd/compile: handle ++/-- in noder2 for operands with generic type
types2 will have already proved the expression's type is compatible, so
just assign the one const to have the same type as the operand.
Fixes #47258.
Change-Id: If0844e6bf6d0a5e6b11453b87df71353863ccc5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/336009
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Dan Scales [Tue, 20 Jul 2021 16:37:35 +0000 (09:37 -0700)]
[dev.typeparams] cmd/compile: added a builtins.go test, fixed one bug
The builtins.go test is derived from
cmd/compile/internal/types2/testdata/check/builtins.go2, after removing
the error cases. Added a few extra tests for len/cap/append.
Fixed one bug, which is that DELETE operations can't be transformed if
their argument is a typeparam. Also, the tranform of LEN/CAP calls does
not need to be delayed. Removed out-date references to the old
typechecker in the comments.
Change-Id: If7a21506a7ff63ff7c8e87ccd614ef4ff3a0d3c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/336010
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Keith Randall [Tue, 20 Jul 2021 22:02:01 +0000 (15:02 -0700)]
[dev.typeparams] cmd/compile: get runtime stuff working
Remaining stuff from Dan's CL 335412 to get tests passing.
- Removed PTRLIT case in node() that was added with the gcshape change.
I don't think it is needed anymore.
- Modified (*itab).init() to add an irrelevant pointer (the itab
itself) for the '==' entry of interfaces with 'comparable'. That
entry is not used, so we just want to avoid the error that the given
type doesn't actually have an '==' method.
Change-Id: I9b2d4c8342c0b2048d76e003d95023f4ccd559f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/336149
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Keith Randall [Tue, 20 Jul 2021 21:52:19 +0000 (14:52 -0700)]
[dev.typeparams] cmd/compile: avoid adding incorrectly instantiated types to the dictionary
FUNCINST nodes aren't instantiated correctly. Skip those types when
adding to the set of types considered for the dictionary. Those types
include those which are uninstantiated(have tparams), and those with
type parameters that aren't a parameter of the containing function
(they are the type parameter of the function being called).
Allow func types to be put in the dictionary.
Change-Id: I26bab85d3eebc2f54d02b4bba5e31407faf7c5b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/336129 Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Keith Randall [Tue, 20 Jul 2021 19:55:51 +0000 (12:55 -0700)]
[dev.typeparams] cmd/compile: ensure methods of generic types survive linker pruning
Calling MarkTypeUsedInInterface before inlining is problematic (when
using the containing function as the reference source), because we end
up attaching a relocation to the original function, which is then
deadcode removed because all instances of it were inlined. (All other
current uses of MarkTypeUsedInInterface happen after inlining, so they
don't have this problem.)
Instead, attach the relocation to the dictionary in which the type
appears. This should always work, because if the dictionary is ever
deadcode eliminated, then the type can never be put in an interface,
which means we indeed don't need its methods.
This CL is a bit overkill, as not *all* types in the dictionary need
this mark, but it is sufficient for now.
Change-Id: I2d39456691f1c3df8efe3bddc3b9017e0ef37a7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/336012
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com>
We'll have to revisit eventually, but disabling for now.
Change-Id: Ic34cfe451939d61884079bb125b9290db1e05e47
Reviewed-on: https://go-review.googlesource.com/c/go/+/335829
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com>