Commit graph

60 commits

Author SHA1 Message Date
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
Dan Scales d48f6d9f6f [dev.typeparams] Don't check typecheck(3) on transform, so no need to export/import it
We have a value typecheck(3) that indicates that a node in a generic
function still needs transformation (via the functions in transform.go).
But it is not very desirable to export/import the value of typecheck(3).
So, I changed the stenciling code to just try to transform all relevant
node types during node copy. Almost all tranform functions were already
idempotent. I only had to add an extra if check before calling
transformAssign() in the OAS case. We still use the typecheck(3) in
noder to determine when higher-nodes have to delay transformation
because one or more of their args are delaying transformation.

Added new test mapsimp.go that required these tranformations after import.

As an additional change, export/import of OINDEX requires exporting the
type using w.exoticType() rather than w.typ(), in order to handle
generic functions. Since generic functions can have pre-transform
operations, the index operation can have a tuple type (multiple return
from a map lookup).

Added printing of imported function bodies in -W=3 debug mode.

Change-Id: I220e2428dc5f2741e91db146f075eb5b6045f451
Reviewed-on: https://go-review.googlesource.com/c/go/+/322191
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
2021-05-24 22:17:33 +00:00
Dan Scales 4c50721cda [dev.typeparams] cmd/compile: Fix handling of Name nodes during stenciling
The name substitution for stenciling was incorrectly handling non-local
names. Made changes to explicitly built the vars[] name substitution map
based on the local variables (similar to what inlining substitution
does). Then, we we are stenciling a name node, we do NOT make a copy of
the name node if it is not in vars[], since it is then a reference to an
external name. Added new function localvar() to create the new nodes for
the local variables and put them in the vars[] map.

New test listimp2.go, added missing test calls in list2.go

Change-Id: I8946478250c7bf2bd31c3247089bd50cfeeda0fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/322190
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-05-24 22:16:09 +00:00
Dan Scales 5b1120fac7 [dev.typeparams] cmd/compile: fix handling of Nname field in (*subster).tstruct.
We want to keep the Nname references for external function references in
tstruct (not remove them, as is currently happening). We only change the
Nname reference (translate it) when it appears in subst.vars[].

New export/import test sliceimp.go which includes some of these external
function references.

Change-Id: Ie3d73bd989a16082f0cebfb566e0a7faeda55e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/321735
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-05-21 23:25:07 +00:00
Dan Scales 8d2b4cb6cc [dev.typeparams] cmd/compile: fixing import of comm clauses/closures in generic functions
Improvements:
 - Fix export/import of the default case of a select statement (was not
   dealing with nil Comm case)
 - Set properly the name of closure functions in imported generic
   functions

Added new test exporting/importing a reasonably large channel package,
chansimp.go.

Change-Id: If2ee12bd749e5df415f48ec4b629a2fa68a79dcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/321734
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-05-21 23:13:46 +00:00
Dan Scales b1a398cf0f [dev.typeparams] cmd/compile: add import/export of calls to builtin functions
For generic functions, we have to leave the builtins in OCALL form,
rather than transform to specific ops, since we don't know the exact
types involved. Allow export/import of builtins in OCALL form.

Added new export/import test mapimp.go.

Change-Id: I571f8eeaa13b4f69389dbdb9afb6cc61924b9bf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/321750
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-05-21 17:14:19 +00:00
Dan Scales ccbfbb1c33 [dev.typeparams] cmd/compile: export OFUNCINST and OSELRECV2 nodes (for generic functions)
Added new test typeparam/factimp.go and changed a bunch of other tests
to test exporting more generic functions and types.

Change-Id: I573d75431cc92482f8f908695cfbc8e84dbb36d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/321749
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-05-21 17:03:30 +00:00
Dan Scales 7b3ee6102d [dev.typeparams] cmd/compile: move to new export version, keep reading previous version
I added constants for the previous export versions, and for the final
generics export version. I also added a const for the current export
version. We can increment the current export version for unstable
changes in dev.typeparams, and eventally set it back to the generics
version (2) before release. Added the same constants in
typecheck/iexport.go, importer/iimport.go, and gcimporter/iimport.go,
must be kept in sync.

Put in the needed conditionals to be able to read old versions.

Added new export/import test listimp.dir.

Change-Id: I166d17d943e07951aa752562e952b067704aeeca
Reviewed-on: https://go-review.googlesource.com/c/go/+/319931
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-05-21 04:03:26 +00:00
Dan Scales 15ad61aff5 [dev.typeparams] cmd/compile: get export/import of generic types & functions working
The general idea is that we now export/import typeparams, typeparam
lists for generic types and functions, and instantiated types
(instantiations of generic types with either new typeparams or concrete
types).

This changes the export format -- the next CL in the stack adds the
export versions and checks for it in the appropriate places.

We always export/import generic function bodies, using the same code
that we use for exporting/importing the bodies of inlineable functions.

To avoid complicated scoping, we consider all type params as unique and
give them unique names for types1. We therefore include the types2 ids
(subscripts) in the export format and re-create on import. We always
access the same unique types1 typeParam type for the same typeparam
name.

We create fully-instantiated generic types and functions in the original
source package. We do an extra NeedRuntimeType() call to make sure that
the correct DWARF information is written out. We call SetDupOK(true) for
the functions/methods to have the linker automatically drop duplicate
instantiations.

Other miscellaneous details:
 - Export/import of typeparam bounds works for methods (but not
   typelists) for now, but will change with the typeset changes.

 - Added a new types.Instantiate function roughly analogous to the
   types2.Instantiate function recently added.

 - Always access methods info from the original/base generic type, since
   the methods of an instantiated type are not filled in (in types2 or
   types1).

 - New field OrigSym in types.Type to keep track of base generic type
   that instantiated type was based on. We use the generic type's symbol
   (OrigSym) as the link, rather than a Type pointer, since we haven't
   always created the base type yet when we want to set the link (during
   types2 to types1 conversion).

 - Added types2.AsTypeParam(), (*types2.TypeParam).SetId()

 - New test minimp.dir, which tests use of generic function Min across
   packages. Another test stringimp.dir, which also exports a generic
   function Stringify across packages, where the type param has a bound
   (Stringer) as well. New test pairimp.dir, which tests use of generic
   type Pair (with no methods) across packages.

 - New test valimp.dir, which tests use of generic type (with methods
   and related functions) across packages.

 - Modified several other tests (adder.go, settable.go, smallest.go,
   stringable.go, struct.go, sum.go) to export their generic
   functions/types to show that generic functions/types can be exported
   successfully (but this doesn't test import).

Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f
Reviewed-on: https://go-review.googlesource.com/c/go/+/319930
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-21 03:41:18 +00:00
Dan Scales 04f65d394c [dev.typeparams] cmd/compile: fix use of method values with stenciled methods
We were handling the case where an OFUNCINST node was used as a function
value, but not the case when an OFUNCINST node was used as a method
value. In the case of a method value, we need to create a new selector
expression that references the newly stenciled method.

To make this work, also needed small fix to noder2 code to properly set the
Sel of a method SelectorExpr (should be just the base method name, not
the full method name including the type string). This has to be correct,
so that the function created by MethodValueWrapper() can be typechecked
successfully.

Fixes #45817

Change-Id: I7343e8a0d35fc46b44dfe4d45b77997ba6c8733e
Reviewed-on: https://go-review.googlesource.com/c/go/+/319589
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
2021-05-12 22:25:00 +00:00
Keith Randall f432d3fc41 cmd/compile: fix nongeneric closures in generic functions
Ensure that formal parameter Names are correctly copied and marked
with the correct Curfn. We need to ensure this even when the underlying
closure has no type parameters.

(Aside: it is strange that the types of things contain formal
parameter names that need to be copied. Maybe that's an underlying
larger problem that needs to be fixed.)

Fixes #45738

Change-Id: Ia13d69eea992ff7080bd44065115bc52eb624e73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313652
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-04-27 19:30:11 +00:00
Dan Scales 55c517a8b3 cmd/compile: fix handling of ir.CurFunc during stenciling
The transform functions (specifically transformArgs, which is used from
transformCall/transformReturn) require that ir.CurFunc is set correctly.
Since transformCall() is used on the call of an instantiated generic
function, we need to set ir.CurFunc correctly in stencil(). Also,
correctly save/restore ir.CurFunc in genericSubst().

Without this fix, ir.CurFunc can be nil when we call TransformCall()
from stencil(), which leads to some temp variables being added
incorrectly to ir.TodoFunc (which leads to the fatal panic in the
issue).

Fixes #45722

Change-Id: Iddf4a67d28f2100dde8cde5dbc9ca1e00dad6089
Reviewed-on: https://go-review.googlesource.com/c/go/+/313869
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-04-27 16:55:20 +00:00
Keith Randall 083a26c7d2 cmd/compile: propagate pragmas from generic function to stenciled implementation
Change-Id: I28a1910890659aaa449ffd2a847cd4ced5a8600d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310211
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-04-15 00:29:05 +00:00
Dan Scales bf634c76b2 cmd/compile: look for function in instantiations in all global assignments
Add in some missing global assignment ops to the list of globals ops
that should be traversed to look for generic function instantiations.
The most common other one for global assigments (and the relevant one
for this bug) is OAS2FUNC, but also look at global assigments with
OAS2DOTTYPE, OAS2MAPR, OAS2RECV, and OASOP.

Bonus small fix: get rid of -G=3 case in ir.IsAddressable. Now that we
don't call the old typechecker from noder2, we don't need this -G-3
check anymore.

Fixes #45547.

Change-Id: I75fecec55ea0d6f62e1c2294d4d77447ed9be6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/310210
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-04-15 00:14:55 +00:00
Dan Scales f2717b31b5 cmd/compile: deal correctly with unnamed function params during stenciling
During substitution of the function type during stenciling, we must set
the Name nodes of the param/result fields of the func type. We get those
name nodes from the substituted Dcl nodes of the PPARAMS and PPARAMOUTs.
But we must check that the names match with the Dcl nodes, so that we
skip any param fields that correspond to unnamed (in) parameters.

Added a few tests to typelist.go by removing a variety of unneeded
function parameter names.

Change-Id: If786961b64549da6f18eeeb5060ea58fab874eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/305912
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-03-31 00:52:26 +00:00
Dan Scales 1318fb4a32 cmd/compile: handle partial type inference that doesn't require function args
Handle the case where types can be partially inferred for an
instantiated function that is not immediately called. The key for the
Inferred map is the CallExpr (if inferring types required the function
arguments) or the IndexExpr (if types could be inferred without the
function arguments).

Added new tests for the case where the function isn't immediately called
to typelist.go.

Change-Id: I60f503ad67cd192da2f2002060229efd4930dc39
Reviewed-on: https://go-review.googlesource.com/c/go/+/305909
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
2021-03-30 19:44:38 +00:00
Dan Scales 032ef4bbfc cmd/compile: fix creation of named generic types (setting of t.nod)
The correct setting of t.nod is needed when exporting types. Make sure
we create instantiated named types correctly so t.nod is set.

New test file interfacearg.go that tests this (by instantiating a type
with an interface). Also has tests for various kinds of method
expressions.

Change-Id: Ia7fd9debd495336b73788af9e35d72331bb7d2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/305730
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-30 04:48:27 +00:00
Dan Scales eeadfa2d38 cmd/compile: fix various small bugs related to type lists
Fix various small bugs related to delaying transformations due to type
params. Most of these relate to the need to delay a transformation when
an argument of an expression or statement has a type parameter that has
a structural constraint. The structural constraint implies the operation
should work, but the transformation can't happen until the actual value
of the type parameter is known.

 - delay transformations for send statements and return statements if
   any args/values have type params.

 - similarly, delay transformation of a call where the function arg has
   type parameters. This is mainly important for the case where the
   function arg is a pure type parameter, but has a structural
   constraint that requires it to be a function. Move the setting of
   n.Use to transformCall(), since we may not know how many return
   values there are until then, if the function arg is a type parameter.

 - set the type of unary expressions from the type2 type (as we do with
   most other expressions), since that works better with expressions
   with type params.

 - deal with these delayed transformations in subster.node() and convert
   the CALL checks to a switch statement.

 - make sure ir.CurFunc is set properly during stenciling, including
   closures (needed for transforming return statements during
   stenciling).

New test file typelist.go with tests for these cases.

Change-Id: I1b82f949d8cec47d906429209e846f4ebc8ec85e
Reviewed-on: https://go-review.googlesource.com/c/go/+/305729
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-03-30 03:05:45 +00:00
Dan Scales 0265b6475f cmd/compile: replace calls to typecheck with transform functions
For additions, compares, and slices, create transform functions that do
just the transformations for those nodes by the typecheck package (given
that the code has been fully typechecked by types2). For nodes that have
no args with typeparams, we call these transform functions directly in
noder2. But for nodes that have args with typeparams, we have to delay
and call the tranform functions during stenciling, since we don't know
the specific types involved.

We indicate that a node still needs transformation by setting Typecheck
to a new value 3. This value means the current type of the node has been
set (via types2), but the node may still need transformation.

Had to export typcheck.IsCmp and typecheck.Assignop from the typecheck
package.

Added new tests list2.go (required delaying compare typecheck/transform
because of != compare in checkList) and adder.go (requires delaying add
typecheck/transform, since it can do addition for numbers or strings).

There are several more transformation functions needed for expressions
(indexing, calls, etc.) and several more complicated ones needed for
statements (mainly various kinds of assignments).

Change-Id: I7d89d13a4108308ea0304a4b815ab60b40c59b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303091
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-23 04:23:52 +00:00
Dan Scales 90b1ed1602 cmd/compile: get untyped constants working in generic functions
types2 will give us a constant with a type T, if an untyped constant is
used with another operand of type T (in a provably correct way). When we
substitute in the type args during stenciling, we now know the real type
of the constant. We may then need to change the BasicLit.val to be the
correct type (e.g. convert an int64Val constant to a floatVal constant).
Otherwise, later parts of the compiler will be confused.

Updated tests list.go and double.go with uses of untyped constants.

Change-Id: I9966bbb0dea3a7de1c5a6420f8ad8af9ca84a33e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303089
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-18 22:18:32 +00:00
Dan Scales 70d54df4f6 cmd/compile: getting more built-ins to work with generics
For Builtin ops, we currently stay with using the old
typechecker to transform the call to a more specific expression
and possibly use more specific ops. However, for a bunch of the
ops, we delay calling the old typechecker if any of the args have
type params, for a variety of reasons.

In the near future, we will start creating separate functions that do
the same transformations as the old typechecker for calls, builtins,
indexing, comparisons, etc. These functions can then be called at noder
time for nodes with no type params, and at stenciling time for nodes
with type params.

Remove unnecessary calls to types1 typechecker for most kinds of
statements (still need it for SendStmt, AssignStmt, ReturnStmt, and
SelectStmt). In particular, we don't need it for RangeStmt, and this
avoids some complaints by the types1 typechecker on generic code.

Other small changes:
 - Fix check on whether to delay calling types1-typechecker on type
   conversions. Should check if HasTParam is true, rather than if the
   type is directly a TYPEPARAM.

 - Don't call types1-typechecker on an indexing operation if the left
   operand has a typeparam in its type and is not obviously a TMAP,
   TSLICE, or TARRAY. As above, we will eventually have to create a new
   function that can do the required transformations (for complicated
   cases) at noder time or stenciling time.

 - Copy n.BuiltinOp in subster.node()

 - The complex arithmetic example in absdiff.go now works.

 - Added new tests double.go and append.go

 - Added new example with a new() call in settable.go

Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/301951
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-17 16:53:00 +00:00
Dan Scales 832a01aad4 cmd/compile: deal with comparable embedded in a constraint
Ignore an embedded type in an interface which is the predeclared
interface "comparable" (which currently can only be in a type
constraint), since the name doesn't resolve and the "comparable" type
doesn't have any relevant methods (for the purposes of the compiler).

Added new test case graph.go that needs this fix.

Change-Id: I2443d2c3dfeb9d0a78aaaaf91a2808ae2759d247
Reviewed-on: https://go-review.googlesource.com/c/go/+/301831
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-16 18:42:06 +00:00
Dan Scales 96aecdcb36 cmd/compile: fix case where func-valued field of a generic type is called
Added test example orderedmap.go (binary search tree) that requires this
fix (calling function compare in _Map).

Also added new tests slices.go and metrics.go that just work.

Change-Id: Ifa5f42ab6eee9aa54c40f0eca19e00a87f8f608a
Reviewed-on: https://go-review.googlesource.com/c/go/+/301829
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-15 20:29:11 +00:00
Dan Scales c236095638 cmd/compile: add support for generic maps
Add support for maps in subster.typ(). Add new test cases maps.go and set.go.

Change substitution of a TFUNC in subster.typ() to always create new
param and result structs if any of the receiver, param, or result
structs get substituted. All these func structs must be copied, because
they have offset fields that are dependent, and so must have an
independent copy for each new signature (else there will be an error
later when frame offsets are calculated).

Change-Id: I576942a62f06b46b6f005abc98f65533008de8dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/301670
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-15 20:28:34 +00:00
Dan Scales dca9c11845 cmd/compile: add support for generic channels and type conversion during calls
Add support for channels in subster.typ(). Add new test file chans.go.

To support assignability of bidirectional channel args to directional
channel params, I needed to type check generic calls after they are
instantiated. (Eventually, we will create separate functions to just do
the assignability logic, so we don't need to call the old typechecker in
this case.) So, for generic calls, we now leave the call as OCALL (as a
signal that the call still needs typechecking), and do typecheck.Call()
during stenciling.

Smaller changes:
 - Set the type of an instantiated OCLOSURE node (and not just the associated
   OFUNC node)

 - In instTypeName2, filter out the space that types2.TypeString inserts
   after a common in a typelist. Our standard naming requires no space
   after the comma.

 - With the assignability fix above, I no longer need the explicit
   conversions in cons.go.

Change-Id: I148858bfc6708c0aa3f50bad7debce2b8c8c091f
Reviewed-on: https://go-review.googlesource.com/c/go/+/301669
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-15 20:28:10 +00:00
Dan Scales e87c4bb3ef cmd/compile: fix noder.Addr() to not call typechecker
Simple change to avoid calling the old typechecker in noder.Addr(). This
fixes cases where generic code calls a pointer method with a non-pointer
receiver.

Added test typeparam/lockable.go that now works with this change.

For lockable.go to work, also fix incorrect check to decide whether to
translate an OXDOT now or later. We should delay translating an OXDOT
until instantiation (because we don't know how embedding, etc. will
work) if the receiver has any typeparam, not just if the receiver type
is a simple typeparam. We also have to handle OXDOT for now in
IsAddressable(), until we can remove calls to the old typechecker in
(*irgen).funcBody().

Change-Id: I77ee5efcef9a8f6c7133564106a32437e36ba4bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/300990
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 02:30:33 +00:00
Dan Scales fdded79e6e cmd/compile: fix handling of partially inferred type arguments
In the case of partially inferred type arguments, we need to use the
IndexExpr as the key in g.info.Inferred[] rather than the CallExpr.

Added an extra fromStrings1 call in the settable.go test that tests
partially inferred type arguments. This new call uses a new concrete
type SettableString as well.

I also added another implementation fromStrings3 (derived from a go2go
tests) that typechecks but intentionally causes a panic.

Change-Id: I74d35c5a741f72f37160a96fbec939451157f392
Reviewed-on: https://go-review.googlesource.com/c/go/+/300309
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-11 00:31:14 +00:00
Dan Scales 1811aeae66 cmd/compile: deal with helper generic types that add methods to T
Deal with cases like: 'type P[T any] T' (used to add methods to an
arbitrary type T), In this case, P[T] has kind types.TTYPEPARAM (as does
T itself), but requires more code to substitute than a simple TTYPEPARAM
T. See the comment near the beginning of subster.typ() in stencil.go.

Add new test absdiff.go. This test has a case for complex types (which
I've commented out) that will only work when we deal better with Go
builtins in generic functions (like real and imag).

Remove change in fmt.go for TTYPEPARAMS that is no longer needed (since
all TTYPEPARAMS have a sym) and was sometimes causing an extra prefix
when formatting method names.

Separate out the setting of a TTYPEPARAM bound, since it can reference
the TTYPEPARAM being defined, so must be done separately. Also, we don't
currently (and may not ever) need bounds after types2 typechecking.

Change-Id: Id173057e0c4563b309b95e665e9c1151ead4ba77
Reviewed-on: https://go-review.googlesource.com/c/go/+/300049
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-10 17:36:55 +00:00
Dan Scales a70eb2c9f2 cmd/compile: get instantiated generic types working with interfaces
Get instantiatiated generic types working with interfaces, including
typechecking assignments to interfaces and instantiating all the methods
properly. To get it all working, this change includes:

 - Add support for substituting in interfaces in subster.typ()

 - Fill in the info for the methods for all instantiated generic types,
   so those methods will be available for later typechecking (by the old
   typechecker) when assigning an instantiated generic type to an
   interface. We also want those methods available so we have the list
   when we want to instantiate all methods of an instantiated type. We
   have both for instantiated types encountered during the initial noder
   phase, and for instantiated types created during stenciling of a
   function/method.

 - When we first create a fully-instantiated generic type (whether
   during initial noder2 pass or while instantiating a method/function),
   add it to a list so that all of its methods will also be
   instantiated. This is needed so that an instantiated type can be
   assigned to an interface.

 - Properly substitute type names in the names of instantiated methods.

 - New accessor methods for types.Type.RParam.

 - To deal with generic types which are empty structs (or just don't use
   their type params anywhere), we want to set HasTParam if a named type
   has any type params that are not fully instantiated, even if the
   type param is not used in the type.

 - In subst.typ() and elsewhere, always set sym.Def for a new forwarding
   type we are creating, so we always create a single unique type for
   each generic type instantiation. This handles recursion within a
   type, and also recursive relationships across many types or methods.
   We remove the seen[] hashtable, which was serving the same purpose,
   but for subst.typ() only. We now handle all kinds of recursive types.

 - We don't seem to need to force types.CheckSize() on
   created/substituted generic types anymore, so commented out for now.

 - Add an RParams accessor to types2.Signature, and also a new
   exported types2.AsSignature() function.

Change-Id: If6c5dd98427b20bfe9de3379cc16f83df9c9b632
Reviewed-on: https://go-review.googlesource.com/c/go/+/298449
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-09 16:37:52 +00:00
Dan Scales d8e33d558e cmd/compile: deal with closures in generic functions and instantiated function values
- Deal with closures in generic functions by fixing the stenciling code

 - Deal with instantiated function values (instantiated generic
   functions that are not immediately called) during stenciling. This
   requires changing the OFUNCINST node to an ONAME node for the
   appropriately instantiated function. We do this in a second pass,
   since this is uncommon, but requires editing the tree at multiple
   levels.

 - Check global assignments (as well as functions) for generic function
   instantiations.

 - Fix a bug in (*subst).typ where a generic type in a generic function
   may definitely not use all the type args of the function, so we need
   to translate the rparams of the type based on the tparams/targs of
   the function.

 - Added new test combine.go that tests out closures in generic
   functions and instantiated function values.

 - Added one new variant to the settable test.

 - Enabling inlining functions with closures for -G=3. (For now, set
   Ntype on closures in -G=3 mode to keep compatibility with later parts
   of compiler, and allow inlining of functions with closures.)

Change-Id: Iea63d5704c322e42e2f750a83adc8b44f911d4ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/296269
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
2021-02-26 18:57:20 +00:00
Dan Scales 20050a15fe [dev.typeparams] cmd/compile: support generic types (with stenciling of method calls)
A type may now have a type param in it, either because it has been
composed from a function type param, or it has been declared as or
derived from a reference to a generic type. No objects or types with
type params can be exported yet. No generic type has a runtime
descriptor (but will likely eventually be associated with a dictionary).

types.Type now has an RParam field, which for a Named type can specify
the type params (in order) that must be supplied to fully instantiate
the type. Also, there is a new flag HasTParam to indicate if there is
a type param (TTYPEPARAM) anywhere in the type.

An instantiated generic type (whether fully instantiated or
re-instantiated to new type params) is a defined type, even though there
was no explicit declaration. This allows us to handle recursive
instantiated types (and improves printing of types).

To avoid the need to transform later in the compiler, an instantiation
of a method of a generic type is immediately represented as a function
with the method as the first argument.

Added 5 tests on generic types to test/typeparams, including list.go,
which tests recursive generic types.

Change-Id: Ib7ff27abd369a06d1c8ea84edc6ca1fd74bbb7c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/292652
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-02-18 22:37:06 +00:00