Commit graph

10 commits

Author SHA1 Message Date
Dan Scales
3f845b3b45 [dev.typeparams] cmd/compile: deal with inferred type arguments
Create an extra OFUNCINST node as needed, if there are inferred type
arguments for a generic function call.

Change-Id: Id990c5bcbce2893377072a7e41c7c6785d1eab60
Reviewed-on: https://go-review.googlesource.com/c/go/+/288952
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-02-03 02:15:51 +00:00
Dan Scales
e633f343ba [dev.typeparams] cmd/compile: add OFUNCINST/OTYPEINST nodes for generic func/type instantiation
Expresses things more clearly, especially in cases like 'f := min[int]'
where we create a xsgeneric function instantiation, but don't immediately
call it.

min[int](2, 3) now looks like:

.   CALLFUNC tc(1) Use:1 int # min1.go:11 int
.   .   FUNCINST tc(1) FUNC-func(int, int) int # min1.go:11 FUNC-func(int, int) int
.   .   .   NAME-main.min tc(1) Class:PFUNC Offset:0 Used FUNC-func[T](T, T) T # min1.go:3
.   .   FUNCINST-Targs
.   .   .   TYPE .int Offset:0 type int
.   CALLFUNC-Args
.   .   LITERAL-2 tc(1) int # min1.go:11
.   .   LITERAL-3 tc(1) int # min1.go:11

Remove the targs parameter from ir.NewCallExpr(), not needed anymore,
since type arguments are included in the FUNCINST.

Change-Id: I23438b75288330475294d7ace239ba64acfa641e
Reviewed-on: https://go-review.googlesource.com/c/go/+/288951
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-02-03 01:18:23 +00:00
Dan Scales
3d5c715bf2 [dev.typeparams] Handling multiple type arguments for call via new node OLIST
Will now run "go tool compile -G=2 -W=2" on a simple generic function
with multiple type parameters and a call to that function with multiple
explicit type arguments.

We will likely move to have a separate function/type instantiation node,
in order distinguish these cases from normal index expressions.

Change-Id: I0a571902d63785cc06240ed4ba0495923403b511
Reviewed-on: https://go-review.googlesource.com/c/go/+/288433
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-02-02 19:14:08 +00:00
Dan Scales
13a7412983 [dev.typeparams] Parse a generic type arg for generic function call
Will now run "go tool compile -G=2 -W=2" on a simple generic function
with one type parameter and a call to that function with one explicit
type argument. Next change will handle multiple type arguments.

Change-Id: Ia7d17ea2a02bf99bd50e673ac80ae4aad4c48440
Reviewed-on: https://go-review.googlesource.com/c/go/+/288432
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-02-01 22:05:52 +00:00
Dan Scales
2440dd457a [dev.typeparams] cmd/compile: start adding info needed for typeparams in types & ir
We are focusing on generic functions first, and ignoring type lists for
now.

The signatures of types.NewSignature() and ir.NewCallExpr() changed (with
addition of type args/params).

Change-Id: I57480be3d1f65690b2946e15dd74929bf42873f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/287416
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
2021-01-28 20:28:11 +00:00
Dan Scales
08a598f8c1 [dev.typeparams] cmd/compile: fix MethodExpr handling with embedded fields
The recent refactoring of SelectorExpr code to helpers broke the
handling of MethodExprs when there is an embedded field involved (e.g.
test/method7.go, line 48). If there is an embedded field involved, the
node op seen in DotMethod() is an ODOT rather than an OTYPE. Also, the
receiver type of the result should be the original type, but the new
code was using the last type after following the embedding path.

Change-Id: I13f7ea6448b03d3e8f974103ee3a027219ca8388
Reviewed-on: https://go-review.googlesource.com/c/go/+/286176
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-01-26 17:05:06 +00:00
Matthew Dempsky
2b95c28b18 [dev.typeparams] cmd/compile: refactor SelectorExpr code into helpers
This CL refactors the SelectorExpr-handling code added in CL 285373
into helper functions that can eventually be reused by iimport.

Change-Id: I15b4a96c242f63cb370d7492ed08168550724f47
Reviewed-on: https://go-review.googlesource.com/c/go/+/285953
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>
2021-01-23 01:20:17 +00:00
Dan Scales
12cd9cf7e0 [dev.typeparams] cmd/compile: disambiguate OXDOT in noder using types2 Selection info
By using the types2 Selection information, we can create ODOT, ODOTPTR,
OCALLPART, ODOTMETH, ODOTINTER, and OMETHEXPR nodes directly in noder,
so we don't have to do that functionality in typecheck.go. Intermediate
nodes are created as needed for embedded fields. Don't have to typecheck
the results of g.selectorExpr(), because we set the types of all the
needed nodes.

There is one bug remaining in 'go test reflect' that will be fixed when dev.regabi is merged.

Change-Id: I4599d43197783e318610deb2f208137f9344ab63
Reviewed-on: https://go-review.googlesource.com/c/go/+/285373
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-01-22 17:16:22 +00:00
Matthew Dempsky
2427f6e6c0 [dev.typeparams] cmd/compile: directly set some simple expression types
This CL updates irgen to directly set the type for a bunch of basic
expressions that are easy to handle already. Trickier rewrites are
still handled with typecheck.Expr, but responsibility of calling that
is pushed down to the conversion of individual operations.

Change-Id: I774ac6ab4c72ad854860ab5c741867dd42a066b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/285058
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
2021-01-21 01:25:11 +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