Commit graph

90 commits

Author SHA1 Message Date
Keith Randall 2fbf6aafe7 [dev.typeparams] cmd/compile: handle interface type parameters in type switches
Change-Id: I9bba21a64d7e9f42395b6fcdf8aa3ca01cf131dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/340912
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
2021-08-10 01:56:50 +00:00
Robert Griesemer e4cfa2f6da [dev.typeparams] cmd/compile/internal/types2: parameterized functions must have a body
Add the respective check and add missing bodies to tests.
Use {} as body for functions that don't return a result.
Use { panic(0) } as body for functions that return a result.

For #47069.

Change-Id: Ia5d7525c9c036baf8a955d13bff448401e08235e
Reviewed-on: https://go-review.googlesource.com/c/go/+/340911
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
2021-08-10 01:20:34 +00:00
Dan Scales 9f4d6a8359 [dev.typeparams] cmd/compile: call transformArgs before early typecheckaste in noder
In the cases where we do an early call to typecheckaste() in noder to
expose CONVIFACE nodes, we need a preceding call to transformArgs().
This is needed to allow typecheckaste() to run correctly, in the case of
f(g()), where g has multiple return values.

I also cleaned up the code a bit and commented the code in Call(), and
we do the call to typecheckaste() in several more cases.

In stencil.go:stencil(), I moved the transformCall earlier for the
OCALLMETH/ODOTMETH case, just as I did in my previous CL for
OCALL/OFUNCINST. By doing this, transformArgs no longer needs to deal
with the extra dictionary args. Therefore, I was able to simply
transformArgs() to look like typecheckargs() again, and make use of
RewriteMultiValue directly.

Updates #47514

Change-Id: I49eb82ac05707e50c2e2fb03e39458a70491d406
Reviewed-on: https://go-review.googlesource.com/c/go/+/340531
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>
2021-08-09 19:43:09 +00:00
Keith Randall ca3c6985cd [dev.typeparams] cmd/compile: implement generic type switches
Add a new dynamicType node, which is used as a case entry when
the type being switched to is generic.

Change-Id: Ice77c6f224b8fdd3ff574fdf4a8ea5f6c7ddbe75
Reviewed-on: https://go-review.googlesource.com/c/go/+/339429
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
2021-08-09 18:41:45 +00:00
Robert Griesemer 0811108670 [dev.typeparams] cmd/compile/internal/types2: fix make with type parameter argument
For make with a type parameter argument, the structural type of
the type parameter's constraint determines what make is making.

Change-Id: I3b48f8ce3236b7624e0638b5f5be208c5915c987
Reviewed-on: https://go-review.googlesource.com/c/go/+/339899
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>
2021-08-06 20:34:46 +00:00
Dan Scales ac78501b9c [dev.typeparams] cmd/compile: make sure closures inside generic funcs are not compiled
Closures inside generic functions were being added to the g.target.Decls
list during noding, just like other closures. We remove generic
functions/methods from g.target.Decls, so they don't get compiled
(they're only available for export and stenciling). Most closures inside
generic functions/methods were similarly being removed from
g.target.Decls, because they have a generic parameter. But we need to
ensure no closures in generic function/methods are left remaining in
g.target.Decls, since we don't want them transformed and compiled.

So, we set a flag in (*irgen) that records when we are noding a
top-level generic function/method, and don't add any closures to
g.target.Decls when the flag is true.

Updates #47514

Change-Id: Id66b4c41d307ffa8f54cab6ce3646ade81606862
Reviewed-on: https://go-review.googlesource.com/c/go/+/340258
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-08-06 18:50:46 +00:00
Robert Griesemer bb5608dd5d [dev.typeparams] cmd/compile/internal/types2: implement type sets with term lists
This CL resolves several known issues and TODOs.

- Represent type sets with term lists and using term list abstractions.

- Represent Unions internally as a list of (syntactical) terms.
  Use term operations to print terms and detect overlapping union
  entries.

- Compute type sets corresponding to unions lazily, on demand.

- Adjust code throughout.

- Adjusted error check in test/typeparam/mincheck.dir/main.go
  to make test pass.

Change-Id: Ib36fb7e1d343c2b6aec51d304f0f7d1ad415f999
Reviewed-on: https://go-review.googlesource.com/c/go/+/338310
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
2021-08-05 19:36:47 +00:00
Dan Scales 3cdf8b429e [dev.typeparams] cmd/compile: fixing case where type arg is an interface
In this case, we can't use an itab for doing a bound call, since we're
converting from an interface to an interface. We do a static or dynamic
type assert in new function assertToBound().

The dynamic type assert in assertToBound() is only needed if a bound is
parameterized. In that case, we must do a dynamic type assert, and
therefore need a dictionary entry for the type bound (see change in
getGfInfo). I'm not sure if we can somehow limit this case, since using
an interface as a type arg AND having the type bound of the type
arg be parameterized is a very unlikely case.

Had to add the TUNION case to parameterizedBy1() (which is only used for
extra checking).

Added a bunch of these test cases to 13.go, which now passes.

Change-Id: Ic22eed637fa879b5bbb46d36b40aaad6f90b9d01
Reviewed-on: https://go-review.googlesource.com/c/go/+/339898
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-08-05 17:33:41 +00:00
Keith Randall b730a26729 [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:

$ objdump -d a.exe | grep _a\.F
 1053cb0:	e8 8b 00 00 00 	callq	139 <_a.F[.shape.*uint8]>
 1053ce9:	e8 52 00 00 00 	callq	82 <_a.F[.shape.*uint8]>
_a.F[.shape.*uint8]:
 1053d90:	e8 ab ff ff ff 	callq	-85 <_a.F[.shape.*uint8]>
 1053dc9:	e8 72 ff ff ff 	callq	-142 <_a.F[.shape.*uint8]>

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>
2021-08-04 17:56:00 +00:00
Keith Randall 0b8a9ccb25 [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>
2021-07-31 17:03:07 +00:00
Keith Randall 40e561d933 [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>
2021-07-30 21:01:32 +00:00
Dan Scales 600b7b431b [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>
2021-07-29 21:58:06 +00:00
Keith Randall f4f503e0a3 [dev.typeparams] cmd/compile: implement generic .(T) operations
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>
2021-07-29 17:15:21 +00:00
Matthew Dempsky adedf54288 [dev.typeparams] test: rename blank functions
This CL renames blank functions in the test/ directory so that they
don't rely on the compiler doing anything more than typechecking them.

In particular, I ran this search to find files that used blank
functions and methods:

$ git grep -l '^func.*\b_(' | xargs grep -n '^' | grep '\.go:1:' | grep -v '// errorcheck$'

I then skipped updating a few files:

* blank.go
* fixedbugs/issue11699.go
* fixedbugs/issue29870.go

  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>
2021-07-28 21:41:07 +00:00
Matthew Dempsky 5355753009 [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>
2021-07-28 21:40:40 +00:00
Robert Griesemer 37d2219960 [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>
2021-07-26 20:53:17 +00:00
Matthew Dempsky bfcb7c4c8a [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>
2021-07-26 18:43:12 +00:00
Keith Randall b27c7e30dc [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>
2021-07-24 22:49:24 +00:00
Dan Scales 8e9109e95a [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>
2021-07-22 04:45:49 +00:00
Dan Scales dcc8350ad3 [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>
2021-07-21 21:30:48 +00:00
Dan Scales f19e49e7b1 [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>
2021-07-21 21:25:20 +00:00
Keith Randall 10c8b7c1d7 [dev.typeparams] cmd/compile: use dictionary to convert arguments of ==, != to interfaces
When comparing a value whose type is a type parameter to an interface,
we need to convert that type parameter to an interface using the dictionary
entries.

Change-Id: I409c9e36e376fe4ef8163407d0fd4e84496d5b65
Reviewed-on: https://go-review.googlesource.com/c/go/+/334150
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>
2021-07-16 18:31:15 +00:00
Dan Scales ed9e109dc9 [dev.typeparams] cmd/compile: fix small -G=3 issues for tests disabled in run.go
- set correct position for closure capture variable in (*irgen).use()
   (issue20250.go) Also, evaluate rhs, lhs in that order in assignment
   statements to match noder1 (affects ordering of closure variables).

 - make sure to set Assign flag properly in (*irgen).forStmt() for range
   variables which are map accesses (issue9691.go)

 - make sure CheckSize() is call on the base type for top-level types
   converted by (*irgen).typ() that are pointer types (issue20174.go and
   issue37837.go)

 - deal with parentheses properly in validation function
   (*irgen).validate() (issue17270.go)

 - avoid HasNil call on type TTYPEPARAM - types2 typechecker will have
   already checked validity of the typeparam having nil value (new test
   issue39755.go)

Change-Id: Ie68004d964698aea047e19e7dcd79b297e9d47ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/334733
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>
2021-07-16 18:30:16 +00:00
Robert Griesemer 3d8453e00e [dev.typeparams] cmd/compile/internal/types2: more consistent handling of predeclared "any"
Rather than removing "any" from the universe scope, keep it predeclared
but provide a better error message.

While at it, remove some unnecessary type assertions.

Change-Id: I10603274282ea6afc107f703ab194f32bd334dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/334911
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>
2021-07-16 04:41:47 +00:00
Robert Griesemer 4ff0e04c2e [dev.typeparams] cmd/compile/internal/types2: embedding stand-alone type parameters is not permitted
For #47127.

Change-Id: Ie979ff56ae7c2dd0e5ce0ff39588f98ae68b5ee9
Reviewed-on: https://go-review.googlesource.com/c/go/+/334151
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>
2021-07-14 23:33:52 +00:00
Dan Scales 1c783dc148 [dev.typeparams] Add optional sub-dict entry for typeparam bound calls
In the case that a generic function/method f does a method call on a
type param allowed by its bound, an instantiation of f may do a direct
method call of a concrete type or a method call defined on a generic
type, depending on whether the passed type in a concrete type or an
instantiated type with the appropriate method defined. See the test case
boundmethod.go added to this change.

In order to keep the dictionary format the same for all instantiations
of a generic function/method, I decided to have an optional
sub-dictionary entry for "bounds" calls. At the point that we are
creating the actual dictionary, we can then fill in the needed
sub-dictionary, if the type arg is an instantiated type, or a zeroed
dictionary entry, if type arg is not instantiated and the method will be
on a concrete type.

In order to implement this, I now fill in n.Selection for "bounds"
method calls in generic functions as well. Also, I need to calculate
n.Selection correctly during import for the case where it is now set -
method calls on generic types, and bounds calls on typeparams.

With this change, the dictionaries/sub-dictionaries are correct for
absdiff.go. The new test boundmethod.go illustrates the case where the
bound sub-dict entry is not used for a dictionary for stringify[myint],
but is used for a dictionary for stringify[StringInt[myint]].

Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457
Reviewed-on: https://go-review.googlesource.com/c/go/+/333456
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>
2021-07-12 16:09:57 +00:00
Dan Scales 501725032c [dev.typeparams] cmd/compile: handle derived types that are converted to interfaces
Up to this point, we were only handling typeparams that were converted
to empty or non-empty interfaces. But we have a dictionary entry for
each derived type (i.e. type derived from typeparams) as well. So, when
doing a conversion, look for the source type in both the type params and
derived types of the generic info, and then use the appropriate
dictionary entry.

Added some cases to ifaceconv.go (e.g. converting []T to an empty
interface).

Change-Id: I7bbad0128bec20ccccd93ae1d65c1ffd44ca79a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/333011
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>
2021-07-07 17:40:11 +00:00
Dan Scales b4844c9f54 [dev.typeparams] cmd/compile: handle the (*T).M method expression with dictionaries
The (*T).M method expression is where M is a value method, but the type
(*T) is a pointer to the main type. In this case, after following any
embedded fields, we need to add an extra star operator when using the
receiver arg in the closure call.

Thanks to Cuong for finding/pointing out an example for this case
(typeparam/mdempsky/14.go) This example also shows that we now need the
ability to export/import OEFACE and OIDATA, which I added.

Change-Id: Ida0f81ce757fff78fec6276c60052ed71d207454
Reviewed-on: https://go-review.googlesource.com/c/go/+/333014
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
2021-07-07 17:31:57 +00:00
Matthew Dempsky 5c42b6a953 [dev.typeparams] test: add regress tests that fail(ed) with -G=3
This CL includes multiple test cases that exercise unique failures
with -G=3 mode that did not affect unified IR mode. Most of these were
found over a period of about 3 hours of manual experimentation.

Thanks to Cuong Manh Le for test cases 11 and 12.

Updates #46704.

Change-Id: Ia2fa619536732b121b6c929329065c85b9384511
Reviewed-on: https://go-review.googlesource.com/c/go/+/326169
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-07-07 11:12:24 +00:00
Matthew Dempsky 49ade6b298 [dev.typeparams] test: add expected failure mechanism
This CL changes the existing excluded-test mechanism into a
known-failure mechanism instead. That is, it runs the test regardless,
but only reports if it failed (or succeeded) unexpectedly.

It also splits the known failures list into fine-grain failure lists
for types2, types2 w/ 32-bit target, -G=3, and unified.

Updates #46704.

Change-Id: I1213cbccf1bab6a92d9bfcf0d971a2554249bbff
Reviewed-on: https://go-review.googlesource.com/c/go/+/332551
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-07-07 11:12:13 +00:00
Dan Scales 6dec18cc75 [dev.typeparams] cmd/compile: start using sub-dictionary entries where needed
Added new struct instInfo for information about an instantiation (of a
generic function/method with gcshapes or concrete types). We use this to
remember the dictionary param node, the nodes where sub-dictionaries
need to be used, etc. The instInfo map replaces the Stencil map in
Package.

Added code to access sub-dictionary entries at the appropriate call
sites. We are currently still calculating the corresponding main
dictionary, even when we really only need a sub-dictionary. I'll clean
that up in a follow-up CL.

Added code to deal with "generic" closures (closures that reference some
generic variables/types). We decided that closures will share the same
dictionary as the containing function (accessing the dictionary via a
closure variable). So, the getGfInfo function now traverses all the
nodes of each closure in a function that it is analyzing, so that a
function's dictionary has all the entries needed for all its closures as
well. Also, the instInfo of a closure is largely shared with its
containing function. A good test for generic closures already exists
with orderedmap.go.

Other improvements:
 - Only create sub-dictionary entries when the function/method
   call/value or closure actually has type params in it. Added new test
   file subdict.go with an example where a generic method has an
   instantiated method call that does not depend not have type params.

Change-Id: I691b9dc024a89d2305fcf1d8ba8540e53c9d103f
Reviewed-on: https://go-review.googlesource.com/c/go/+/331516
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>
2021-07-02 19:07:06 +00:00
Dan Scales 8767b87ab5 [dev.typeparams] cmd/compile: functions to create GC shape types/names for a concrete type
Created functions to create GC shape type and names, based on a proposal
from Keith. Kept unsigned and signed integer types as different, since
they have different shift operations.

Included adding in alignment fields where padding is
required between fields, even though that seems like it will be fairly
uncommon to use.

Added some extra unusual struct typeparams (for testing the gcshape
names/types) in index.go test.

Change-Id: I8132bbd28098bd933435b8972ac5cc0b39f4c0df
Reviewed-on: https://go-review.googlesource.com/c/go/+/329921
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>
2021-06-30 20:51:17 +00:00
Keith Randall 6a5f7e8498 [dev.typeparams] cmd/compile: use dictionary entries for more conversion cases
This CL handles I(x) where I is an interface type and x has
typeparam type.

Change-Id: Ib99de2b741d588947f5e0164255f6365e98acd8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/326189
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>
2021-06-29 21:50:53 +00:00
Matthew Dempsky f4198f85d5 [dev.typeparams] cmd/compile: generate wrappers within unified IR
This CL extends unified IR to handle creating wrapper methods. There's
relatively little about this code that's actually specific to unified
IR, but rewriting this logic allows a few benefits:

1. It decouples unified IR from reflectdata.methodWrapper, so the
latter code can evolve freely for -G=3's needs. This will also allow
the new code to evolve to unified IR's wrapper needs, which I
anticipate will operate slightly differently.

2. It provided an opportunity to revisit a lot of the code and
simplify/update it to current style. E.g., in the process, I
discovered #46903, which unified IR now gets correctly. (I have not
yet attempted to fix reflectdata.methodWrapper.)

3. It gives a convenient way for unified IR to ensure all of the
wrapper methods it needs are generated correctly.

For now, the wrapper generation is specific to non-quirks mode.

Change-Id: I5798de6b141f29e8eb6a5c563e7049627ff2868a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330569
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>
2021-06-25 05:00:20 +00:00
Dan Scales ddb09af1b8 [dev.typeparams] cmd/compile: add derived types and subdictionaries to dictionaries
This is code in progress to generate the two main other types of entries
in dictionaries:
 - all types in the instantiated function derived from the type
   arguments (which are currently concrete, but will eventually be
   gcshapes)
 - pointers (i.e. mainly the unique name) to all needed sub-dictionaries

In order to generate these entries, we now generate cached information
gfInfo about generic functions/methods that can be used for creating the
instantiated dictionaries. We use the type substituter to compute the
right type args for instantiated sub-dictionaries.

If infoPrintMode is changed to true, the code prints out all the
information gathered about generic functions, and also the entries in
all the dictionaries that are instantiated. The debug mode also prints
out the locations where we need main dictionaries in non-instantiated
functions.

Other changes:
 - Moved the dictionary generation back to stencil.go from reflect.go,
   since we need to do extra analysis for the new dictionary entries. In
   the process, made getInstantiation generate both the function
   instantiation and the associated dictionary.

 - Put in small change for now in reflect.go, so that we don't try
   generate separate dictionaries for Value[T].get and the
   auto-generated (*Value[T]).get.  The auto-generated wrapper shouldn't really
   need a dictionary.

 - Detected, but not handling yet, a new case which needs
   dictionaries - closures that have function params or captured
   variables whose types are derived from type arguments.

 - Added new tests in dictionaryCapture for use of method
   value/expressions in generic functions and for mutually recursive
   generic functions.

Change-Id: If0cbde8805a9f673a23f5ec798769c85c9c5359b
Reviewed-on: https://go-review.googlesource.com/c/go/+/327311
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>
2021-06-24 20:11:51 +00:00
Dan Scales ee4fc0c1bc [dev.typeparams] Fix issues related to dictionaries and method calls with embedded fields
- Fix handling of method expressions with embedded fields. Fix an
   incorrect lookup for method expressions, which have only the
   top-level type (and don't have DOT operations for the embedded
   fields). Add the embedded field dot operations into the closure.

 - Don't need a dictionary and so don't build a closure if the last
   embedded field reached in a method expression is an interface value.

 - Fix methodWrapper() to use the computed 'dot' node in the
   generic-only part of the code.

 - For a method expression, don't create a generic wrapper if the last
   embedded field reached before the method lookup is an interface.

Copied cmd/compile/internal/types2/testdata/fixedbugs/issue44688.go2 to
test/typeparam/issue44688.go, made it fully runnable (rather than just
for compilation), and added a bunch more tests.

Change-Id: I90c1aa569e1c7272e986c9d2ae683e553c3a38a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/329550
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>
2021-06-23 23:38:05 +00:00
Matthew Dempsky 1ba2074440 [dev.typeparams] cmd/compile/internal/types2: support local defined types
This CL changes types2's instance hashing logic to include position
information for function-scope defined types as disambiguation. This
isn't ideal, but it worked for getting nested.go passing.

Updates #46592.

Change-Id: Id83ba0001f44af69b81260306cc8b05e44fc4f09
Reviewed-on: https://go-review.googlesource.com/c/go/+/327170
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
2021-06-16 21:38:50 +00:00
Matthew Dempsky db7c868307 [dev.typeparams] test: add string quoting support to test/run.go
This CL copies go/build's splitQuoted function (used for parsing #cgo
directives within `import "C"` preambles) to parse test recipe
commands. In particular, this now allows writing "build" and "run"
tests that use -gcflags to pass multiple compiler flags.

Change-Id: I0d18a9c13a4ce24bbdfa1da8662c0498c93a6762
Reviewed-on: https://go-review.googlesource.com/c/go/+/327275
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>
2021-06-12 14:36:25 +00:00
Keith Randall cf4b6dc48e [dev.typeparams] cmd/compile: allow conversions from type parameter to interface
When converting from a type param to an interface, allow it if
the type bound implements that interface.

Query: some conversions go through this path, some use another path?
The test does

   var i interface{foo()int} = x

but

   i := (interface{foo()int})(x)

works at tip.

Change-Id: I84d497e5228c0e1d1c9d76ffebaedce09dc45e8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/325409
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>
2021-06-07 19:53:38 +00:00
Dan Scales 201d55e637 [dev.typeparams] cmd/compile: create .dict Param in the package of the instantiated function
The instantiated functions are created in the source package of the
generic function, so all lookups of symbols should be relative to that
package, so all symbols are consistently in the source package.

Fixes #46575

Change-Id: Iba67b2ba8014a630c5d4e032c0f2f2fbaaedce65
Reviewed-on: https://go-review.googlesource.com/c/go/+/325529
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-06-07 19:34:39 +00:00
Keith Randall bad388744b [dev.typeparams] cmd/compile: handle dictionaries for top-level instantiations
There's no outer function in these cases, so we won't be reading
the dictionary as a subdictionary from the outer scope's dictionary.
It will always be a compile-time constant.

Change-Id: I754b126652a6ffb62255734d53fcec29d77cfa9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/324949
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
2021-06-04 18:11:39 +00:00
Dan Scales de61465156 [dev.typeparams] cmd/compile: allow inlining in instantiated functions
Change markType to scan generic types and methods, so that inlineable
functions inside generic functions/methods will be properly marked for
export, which means inlining inside instantiated functions will work
correctly.

Also, fix handling of closures for instantiated functions. Some code
needs to be adjusted, since instantiated functions/methods are compiled
as if in the package of the source generic function/type, rather than in
the local package. When we create the closure struct, we want to make
sure that the .F field has the same package as the other fields for the
closure variables. Also, we need to disable a check in tcCompLit() when
being done for an instantiated function, since fields of the closure
struct will be from the source package, not the local package.

Re-enabled part of the orderedmapsimp test that was disabled because of
these issues.

Change-Id: Ic4dba8917da0a36b17c0bdb69d6d6edfdf14104a
Reviewed-on: https://go-review.googlesource.com/c/go/+/324331
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-06-04 17:48:10 +00:00
Dan Scales 8e6dfe1b31 [dev.typeparams] cmd/compile: export/import of recursive generic types.
Deal with export/import of recursive generic types. This includes
typeparams which have bounds that reference the typeparam.

There are three main changes:

  - Change export/import of typeparams to have an implicit "declaration"
    (doDecl). We need to do a declaration of typeparams (via the
    typeparam's package and unique name), because it may be referenced
    within its bound during its own definition.

  - We delay most of the processing of the Instantiate call until we
    finish the creation of the top-most type (similar to the way we
    delay CheckSize). This is because we can't do the full instantiation
    properly until the base type is fully defined (with methods). The
    functions delayDoInst() and resumeDoInst() delay and resume the
    processing of the instantiations.

  - To do the full needed type substitutions for type instantiations
    during import, I had to separate out the type subster in stencil.go
    and move it to subr.go in the typecheck package. The subster in
    stencil.go now does node substitution and makes use of the type
    subster to do type substitutions.

Notable other changes:
 - In types/builtins.go, put the newly defined typeparam for a union type
   (related to use of real/imag, etc.) in the current package, rather
   than the builtin package, so exports/imports work properly.

 - In types2, allowed NewTypeParam() to be called with a nil bound, and
   allow setting the bound later. (Needed to import a typeparam whose
   bound refers to the typeparam itself.)

 - During import of typeparams in types2 (importer/import.go), we need
   to keep an index of the typeparams by their package and unique name
   (with id). Use a new map typParamIndex[] for that. Again, this is
   needed to deal with typeparams whose bounds refer to the typeparam
   itself.

 - Added several new tests absdiffimp.go and orderedmapsimp.go. Some of
   the orderemapsimp tests are commented out for now, because there are
   some issues with closures inside instantiations (relating to unexported
   names of closure structs).

 - Renamed some typeparams in test value.go to make them all T (to make
   typeparam uniqueness is working fine).

Change-Id: Ib47ed9471c19ee8e9fbb34e8506907dad3021e5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/323029
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-06-04 16:43:27 +00:00
Dan Scales 370ff5ff96 [dev.typeparams] test: update all the typeparam tests to use the new union/tilde syntax
Did a mix of tilde and non-tilde usage. Tilde notation is not quite
fully functional, so no tests are currently trying to distinguish
(fail/not fail) based on tilde usage.

Change-Id: Ib50cec2fc0684f9d9f3561c889fd44c7a7af458c
Reviewed-on: https://go-review.googlesource.com/c/go/+/324572
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-06-03 16:05:22 +00:00
Dan Scales 97cb0113a3 [dev.typeparams] cmd/compile: fix export/import of constants with typeparam type
A constant will have a TYPEPARAM type if it appears in a place where it
must match that typeparam type (e.g. in a binary operation with a
variable of that typeparam type). If so, then we must write out its
actual constant kind as well, so its constant val can be read in
properly during import.

Fixed some export/import tests which were casting some untyped constants
to avoid this problem.

Change-Id: I285ad8f1c8febbe526769c96e6b27acbd23050f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/324189
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-06-02 23:10:42 +00:00
Keith Randall 7b876def6c [dev.typeparams] cmd/compile: add dictionary argument to generic functions
When converting from a generic function to a concrete implementation,
add a dictionary argument to the generic function (both an actual
argument at each callsite, and a formal argument of each
implementation).

The dictionary argument comes before all other arguments (including
any receiver).

The dictionary argument is checked for validity, but is otherwise unused.
Subsequent CLs will start using the dictionary for, e.g., converting a
value of generic type to interface{}.

Import/export required adding support for LINKSYMOFFSET, which is used
by the dictionary checking code.

Change-Id: I16a7a8d23c7bd6a897e0da87c69f273be9103bd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/323272
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>
2021-06-02 20:23:12 +00:00
Cuong Manh Le 4b10e4c547 [dev.typeparams] cmd/compile: handle ONONAME in subster.node
Fixes #46472

Change-Id: I27802978fa0c3bb32a29e452165a6fcac93473bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/323731
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: Dan Scales <danscales@google.com>
2021-06-01 17:10:20 +00:00
Dan Scales 4ed6317e73 [dev.typeparams] cmd/compile: always generate (*T).M wrappers for instantiated methods
Always generate (*T).M wrappers for instantiated methods, even when the
instantiated method is being generated for another package (its source
package)

Added new function t.IsInstantiated() to check for fully-instantiated
types (generic type instantiated with concrete types, hence concrete
themselves). This function helps hide the representation of instantiated
types outside of the types package.

Added new export/import test setsimp.go that needs this change.

Change-Id: Ifb700db8c9494e1684c93735edb20f4709be5f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/322193
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-05-26 21:39:54 +00:00
Dan Scales b7f7d1cd7b [dev.typeparams] cmd/compile: get type aliases working with generic types
Generic types can the source type of a type alias, so modify g.typ0() to
be able to deal with base generic types.

Added test aliasimp.go that tests aliasing of local generic types and
imported generic types.

Change-Id: I1c398193819d47a36b014cc1f9bb55107e9a565b
Reviewed-on: https://go-review.googlesource.com/c/go/+/322194
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-05-26 21:38:54 +00:00
Dan Scales fd54ae8b0c [dev.typeparams] cmd/compile: adding union support in types1
Add union support in types1, and allow exporting of unions, and
importing unions back into types1 and types2.

Added new test mincheck.go/mincheck.dir that tests that type lists (type
sets) are correctly exported/imported, so that types2 gives correct
errors that an instantiation doesn't fit the type list in the type param
constraint.

Change-Id: I8041c6c79289c870a95ed5a1b10e4c1c16985b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/322609
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-05-26 15:33:02 +00:00