Commit graph

7 commits

Author SHA1 Message Date
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
Matthew Dempsky
f3fc8b5779 [dev.typeparams] cmd/compile: simplify type alias handling for export
Currently the exporter uses types.IsDotAlias(n.Sym()) to recognize
that n is a type alias, but IsDotAlias is actually meant for
recognizing aliases introduced by dot imports. Translated to go/types,
the current logic amounts recognizing type aliases as if by:

	var n *types.TypeName
	typ, ok := n.Pkg().Scope().Lookup(n.Name()).Type().(*types.Named)
	isAlias := !ok || typ.Obj().Pkg() != n.Pkg() || typ.Obj().Name() != n.Name()

But we can instead just check n.Alias() (eqv. n.IsAlias() in
go/types). In addition to being much simpler, this is also actually
correct for recognizing function-scoped type declarations (though we
don't currently support those anyway, nor would they go through this
exact code path).

To avoid possible future misuse of IsDotAlias, this CL also inlines
its trivial definition into its only call site.

Passes toolstash -cmp, also w/ -gcflags=all=-G=3.

Change-Id: I7c6283f4b58d5311aa683f8229bbf62f8bab2ff9
Reviewed-on: https://go-review.googlesource.com/c/go/+/320613
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
2021-05-18 21:18:56 +00:00
Dan Scales
281d168e2d cmd/compile: don't set Ntype in noder2 anymore
Now that we are no longer calling the old typechecker at all during the
noder2 pass, we don't need to create and set an Ntype node ((which is
just a node representation of the type which we already know) for the
Name and Closure nodes. This should reduce memory usage a bit for -G=3.

Change-Id: I6b1345007ce067a89ee64955a53f25645c303f4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/308909
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-09 22:57:48 +00:00
Dan Scales
f47fab938e cmd/compile: remove unneeded calls to typecheck in noder2
Remove unneeded calls to typecheck in noder2 associated with g.use() and
g.obj(). These routines are already setting the types2-derived type
correctly for ONAME nodes, and there is no typechecker1-related
transformations related to ONAME nodes, other than making sure that
newly created closure variables have their type set.

Tested through normal -G=3 testing in all.bash (all of go/tests).

Change-Id: I1b790ab9948959685fca3a768401458201833671
Reviewed-on: https://go-review.googlesource.com/c/go/+/303029
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
2021-03-18 17:14:39 +00:00
Dan Scales
0fbde54ea6 [dev.typeparams] cmd/compile: allow generic funcs to call other generic funcs for stenciling
- Handle generic function calling itself or another generic function in
   stenciling. This is easy - after it is created, just scan an
   instantiated generic function for function instantiations (that may
   needed to be stenciled), just like non-generic functions. The types
   in the function instantiation will already have been set by the
   stenciling.

 - Handle OTYPE nodes in subster.node() (allows for generic type
   conversions).

 - Eliminated some duplicated work in subster.typ().

 - Added new test case fact.go that tests a generic function calling
   itself, and simple generic type conversions.

 - Cause an error if a generic function is to be exported (which we
   don't handle yet).

 - Fixed some suggested changes in the add.go test case that I missed in
   the last review.

Change-Id: I5d61704254c27962f358d5a3d2e0c62a5099f148
Reviewed-on: https://go-review.googlesource.com/c/go/+/290469
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-02-08 19:32:55 +00:00
Matthew Dempsky
493eb6e6ec [dev.typeparams] cmd/compile: fix -G=3 handling of blank methods
Fixes "GO_GCFLAGS=-G=3 go run run.go -- blank.go interface/fail.go".

Change-Id: I669ab06ae29366ce96e2948c89a5c1620afd53db
Reviewed-on: https://go-review.googlesource.com/c/go/+/286214
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
2021-01-25 17:07:38 +00:00
Matthew Dempsky
ef5285fbd0 [dev.typeparams] cmd/compile: add types2-based noder
This CL adds "irgen", a new noding implementation that utilizes types2
to guide IR construction. Notably, it completely skips dealing with
constant and type expressions (aside from using ir.TypeNode to
interoperate with the types1 typechecker), because types2 already
handled those. It also omits any syntax checking, trusting that types2
already rejected any errors.

It currently still utilizes the types1 typechecker for the desugaring
operations it handles (e.g., turning OAS2 into OAS2FUNC/etc, inserting
implicit conversions, rewriting f(g()) functions, and so on). However,
the IR is constructed in a fully incremental fashion, so it should be
easy to now piecemeal replace those dependencies as needed.

Nearly all of "go test std cmd" passes with -G=3 enabled by
default. The main remaining blocker is the number of test/run.go
failures. There also appear to be cases where types2 does not provide
us with position information. These will be iterated upon.

Portions and ideas from Dan Scales's CL 276653.

Change-Id: Ic99e8f2d0267b0312d30c10d5d043f5817a59c9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281932
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>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
2021-01-14 02:07:48 +00:00