aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/expr.go
AgeCommit message (Collapse)Author
2021-03-23cmd/compile: replace calls to typecheck with transform functionsDan Scales
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-18cmd/compile: remove unneeded calls to typecheck in noder2Dan Scales
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-17cmd/compile: getting more built-ins to work with genericsDan Scales
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-12cmd/compile: fix noder.Addr() to not call typecheckerDan Scales
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-11cmd/compile: fix handling of partially inferred type argumentsDan Scales
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-04cmd/compile: remove types2.(*Selection).TArgs(), now that instance bug seems ↵Dan Scales
fixed Previously, we would sometimes see an internal (*instance) type for a receiver of a types2 method, which was a bug. To deal with that, we put in an extra (*Selection).TArgs() method. However, that (*instance) type is no longer showing up for receivers, so we can remove the types2 method we added and do the work with existing types2 API methods. Change-Id: I03e68f5bbaaf82fe706b6efecbb02e951bbd3cd4 Reviewed-on: https://go-review.googlesource.com/c/go/+/298869 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-26cmd/compile: deal with closures in generic functions and instantiated ↵Dan Scales
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-18[dev.typeparams] cmd/compile: use new converter functions rather than ↵Robert Griesemer
methods (fix build) Change-Id: I4dcaca1f2e67ee32f70c22b2efa586232ca519bb Reviewed-on: https://go-review.googlesource.com/c/go/+/293958 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-02-18[dev.typeparams] cmd/compile: support generic types (with stenciling of ↵Dan Scales
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-10[dev.typeparams] cmd/compile: handle calling a method on a type param in ↵Dan Scales
stenciling - Have to delay the extra transformation on methods invoked on a type param, since the actual transformation (including path through embedded fields) will depend on the instantiated type. I am currently doing the transformation during the stencil substitution phase. We probably should have a separate pass after noder2 and stenciling, which drives the extra transformations that were in the old typechecker. - We handle method values (that are not called) and method calls. We don't currently handle method expressions. - Handle type substitution in function types, which is needed for function args in generic functions. - Added stringer.go and map.go tests, testing the above changes (including constraints with embedded interfaces). Change-Id: I3831a937d2b8814150f75bebf9f23ab10b93fa00 Reviewed-on: https://go-review.googlesource.com/c/go/+/290550 TryBot-Result: Go Bot <gobot@golang.org> 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-03[dev.typeparams] cmd/compile: deal with inferred type argumentsDan Scales
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[dev.typeparams] cmd/compile: add OFUNCINST/OTYPEINST nodes for generic ↵Dan Scales
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-02[dev.typeparams] Handling multiple type arguments for call via new node OLISTDan Scales
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-01[dev.typeparams] Parse a generic type arg for generic function callDan Scales
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-01-26[dev.typeparams] cmd/compile: fix MethodExpr handling with embedded fieldsDan Scales
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-23[dev.typeparams] cmd/compile: refactor SelectorExpr code into helpersMatthew Dempsky
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-22[dev.typeparams] cmd/compile: disambiguate OXDOT in noder using types2 ↵Dan Scales
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-21[dev.typeparams] cmd/compile: use nil instead of syntax.ImplicitOneRobert Griesemer
Represent x++/-- as x +=/-= with the RHS of the assignment being nil rather than syntax.ImplicitOne. Dependent code already had to check for syntax.ImplicitOne, but then shared some existing code for regular assignment operations. Now always handle this case fully explicit, which simplifies the code. Change-Id: I28c7918153c27cbbf97b041d0c85ff027c58687c Reviewed-on: https://go-review.googlesource.com/c/go/+/285172 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-01-21[dev.typeparams] cmd/compile: directly set some simple expression typesMatthew Dempsky
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-20[dev.typeparams] cmd/compile: simplify how irgen handles qualified identsMatthew Dempsky
This CL moves qualified identifier handling into expr0 with other selector expressions, rather than as a completely separate special case handled up front. This has a few benefits: 1. It's marginally simpler/cleaner. 2. It allows extra checking for imported objects that they have the same type that types2 thought they had. 3. For imported, untyped constants, we now instead handle them with the "tv.Value != nil" case. In particular, this ensures that they've always already been coerced to the appropriate concrete type by types2. Change-Id: Ibf44ae6901db36aa5251f70934616e9fcbd1cbc5 Reviewed-on: https://go-review.googlesource.com/c/go/+/285053 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-01-14[dev.typeparams] cmd/compile: add types2-based noderMatthew Dempsky
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>