aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/object.go
AgeCommit message (Collapse)Author
2021-07-16[dev.typeparams] cmd/compile: fix small -G=3 issues for tests disabled in run.goDan Scales
- set correct position for closure capture variable in (*irgen).use() (issue20250.go) Also, evaluate rhs, lhs in that order in assignment statements to match noder1 (affects ordering of closure variables). - make sure to set Assign flag properly in (*irgen).forStmt() for range variables which are map accesses (issue9691.go) - make sure CheckSize() is call on the base type for top-level types converted by (*irgen).typ() that are pointer types (issue20174.go and issue37837.go) - deal with parentheses properly in validation function (*irgen).validate() (issue17270.go) - avoid HasNil call on type TTYPEPARAM - types2 typechecker will have already checked validity of the typeparam having nil value (new test issue39755.go) Change-Id: Ie68004d964698aea047e19e7dcd79b297e9d47ca Reviewed-on: https://go-review.googlesource.com/c/go/+/334733 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-26[dev.typeparams] cmd/compile: simplify ~r/~b namingMatthew Dempsky
The compiler renames anonymous and blank result parameters to ~rN or ~bN, but the current semantics for computing N are rather annoying and difficult to reproduce cleanly. They also lead to difficult to read escape analysis results in tests. This CL changes N to always be calculated as the parameter's index within the function's result parameter tuple. E.g., if a function has a single result, it will now always be named "~r0". The normative change to this CL is fairly simple, but it requires updating a lot of test expectations. Change-Id: I58a3c94de00cb822cb94efe52d115531193c993c Reviewed-on: https://go-review.googlesource.com/c/go/+/323010 Trust: Matthew Dempsky <mdempsky@google.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-05-21[dev.typeparams] cmd/compile: get export/import of generic types & functions ↵Dan Scales
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-18[dev.typeparams] cmd/compile: simplify type alias handling for exportMatthew Dempsky
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-04-09cmd/compile: don't set Ntype in noder2 anymoreDan Scales
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-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-02-08[dev.typeparams] cmd/compile: allow generic funcs to call other generic ↵Dan Scales
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-01-25[dev.typeparams] cmd/compile: fix -G=3 handling of blank methodsMatthew Dempsky
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-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>