1
0
mirror of https://github.com/golang/go synced 2024-11-23 14:30:02 -07:00
Commit Graph

2 Commits

Author SHA1 Message Date
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
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