aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/irgen.go
AgeCommit message (Collapse)Author
2021-08-24cmd/compile: change irgen to generate exprs/stmts after decls processedMatthew Dempsky
This CL changes irgen to wait until all top-level declarations have been processed before constructing any expressions or statements that reference them. This is the same approach that typecheck used. Mechanically, it splits varDecl and funcDecl (the two top-level declarations that can generate/contain code) into a part that runs immediately for constructing the ir.ONAME, and then a separate task that runs later to handle the code. It also adds an exprStmtOK flag to indicate when it's actually safe to start constructing (non-trivial) expressions and statements. Fixes #47928. Change-Id: I51942af6823aa561d341e2ffc1142948da025fa2 Reviewed-on: https://go-review.googlesource.com/c/go/+/344649 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: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dan Scales <danscales@google.com>
2021-08-09[dev.typeparams] cmd/compile: implement generic type switchesKeith Randall
Add a new dynamicType node, which is used as a case entry when the type being switched to is generic. Change-Id: Ice77c6f224b8fdd3ff574fdf4a8ea5f6c7ddbe75 Reviewed-on: https://go-review.googlesource.com/c/go/+/339429 Trust: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-08-06[dev.typeparams] cmd/compile: make sure closures inside generic funcs are ↵Dan Scales
not compiled Closures inside generic functions were being added to the g.target.Decls list during noding, just like other closures. We remove generic functions/methods from g.target.Decls, so they don't get compiled (they're only available for export and stenciling). Most closures inside generic functions/methods were similarly being removed from g.target.Decls, because they have a generic parameter. But we need to ensure no closures in generic function/methods are left remaining in g.target.Decls, since we don't want them transformed and compiled. So, we set a flag in (*irgen) that records when we are noding a top-level generic function/method, and don't add any closures to g.target.Decls when the flag is true. Updates #47514 Change-Id: Id66b4c41d307ffa8f54cab6ce3646ade81606862 Reviewed-on: https://go-review.googlesource.com/c/go/+/340258 Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-07-23[dev.typeparams] cmd/compile: add dictionary entries for itab conversionDan Scales
This fix the case where a type param or derived type is converted to a non-empty interface. Previously, we were converting to an empty interface and then using DOTTYPE to convert to the correct non-empty interface. In that case, we can get the needed itab directly from the dictionary. This is needed for correctness from shapes, if the destination interface is parameterized, else we will incorrectly convert to the shape version of the interface. Creating/writing an itab can involve generating wrappers for a bunch of methods, which may use dictionaries. So, all the dictionaries/instantiations are being generated on the fly and have recursive relationships, it is simplest to finish creating/writing the itabs at the end of the stenciling phase. So, we create a list of the dictionaries which need to be completed by writing out their itab entries. The existing tests ordered.go, ifaceconv.go, and issue44688.go make use of this optimization. Got itab conversions for bound calls working, except for 13.go. Also, want to get rid of the concretify, but I think we need more info on the Bound from types2. Change-Id: If552958a7b8a435500d6cc42c401572c367b30d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/336993 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-07-09[dev.typeparams] cmd/compile: report mismatch between types because of ↵Dan Scales
//go:notinheap types2 currently ignores pragmas, so it does not catch a conversion error when converting a pointer to a type which is NOT marked notinheap to a pointer to a convertible type, but which is marked notinheap. So, we specifically check for this error in transformConv() and report it during noder2. Change-Id: I6e9c9ee29f53fa5e490c1ac8306e2191db59eeb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/333369 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Robert Griesemer <gri@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-02[dev.typeparams] cmd/compile: separate out creating instantiations from ↵Dan Scales
creating dictionaries We often need to create a function/method instantiation, but not a dictionary, because the call to the instantiation will be using a sub-dictionary. Also, main dictionaries are only need for concrete, non-gcshape types, whereas instantiations will be for gcshape types (or concrete types, for strict stenciling). Created a helper function getDictOrSubdict() to reduce duplicated code. Also, moved gfGetGfInfo() call in getDictionarySym() inside conditional where it is needed, to avoid extra work when dictionary has already been created. Change-Id: I06587cb2ddc77de2f991e9f9eaf462d2c5a5d45e Reviewed-on: https://go-review.googlesource.com/c/go/+/332550 Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-07-02[dev.typeparams] cmd/compile: start using sub-dictionary entries where neededDan Scales
Added new struct instInfo for information about an instantiation (of a generic function/method with gcshapes or concrete types). We use this to remember the dictionary param node, the nodes where sub-dictionaries need to be used, etc. The instInfo map replaces the Stencil map in Package. Added code to access sub-dictionary entries at the appropriate call sites. We are currently still calculating the corresponding main dictionary, even when we really only need a sub-dictionary. I'll clean that up in a follow-up CL. Added code to deal with "generic" closures (closures that reference some generic variables/types). We decided that closures will share the same dictionary as the containing function (accessing the dictionary via a closure variable). So, the getGfInfo function now traverses all the nodes of each closure in a function that it is analyzing, so that a function's dictionary has all the entries needed for all its closures as well. Also, the instInfo of a closure is largely shared with its containing function. A good test for generic closures already exists with orderedmap.go. Other improvements: - Only create sub-dictionary entries when the function/method call/value or closure actually has type params in it. Added new test file subdict.go with an example where a generic method has an instantiated method call that does not depend not have type params. Change-Id: I691b9dc024a89d2305fcf1d8ba8540e53c9d103f Reviewed-on: https://go-review.googlesource.com/c/go/+/331516 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-06-24[dev.typeparams] cmd/compile: add derived types and subdictionaries to ↵Dan Scales
dictionaries This is code in progress to generate the two main other types of entries in dictionaries: - all types in the instantiated function derived from the type arguments (which are currently concrete, but will eventually be gcshapes) - pointers (i.e. mainly the unique name) to all needed sub-dictionaries In order to generate these entries, we now generate cached information gfInfo about generic functions/methods that can be used for creating the instantiated dictionaries. We use the type substituter to compute the right type args for instantiated sub-dictionaries. If infoPrintMode is changed to true, the code prints out all the information gathered about generic functions, and also the entries in all the dictionaries that are instantiated. The debug mode also prints out the locations where we need main dictionaries in non-instantiated functions. Other changes: - Moved the dictionary generation back to stencil.go from reflect.go, since we need to do extra analysis for the new dictionary entries. In the process, made getInstantiation generate both the function instantiation and the associated dictionary. - Put in small change for now in reflect.go, so that we don't try generate separate dictionaries for Value[T].get and the auto-generated (*Value[T]).get. The auto-generated wrapper shouldn't really need a dictionary. - Detected, but not handling yet, a new case which needs dictionaries - closures that have function params or captured variables whose types are derived from type arguments. - Added new tests in dictionaryCapture for use of method value/expressions in generic functions and for mutually recursive generic functions. Change-Id: If0cbde8805a9f673a23f5ec798769c85c9c5359b Reviewed-on: https://go-review.googlesource.com/c/go/+/327311 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-06-23[dev.typeparams] cmd/compile/internal/syntax: go/ast-style walk APIMatthew Dempsky
This CL adds go/ast's Visitor, Walk, and Inspect functions to package syntax. Having functions with the same API and semantics as their go/ast counterparts reduces the mental load of context switching between go/ast and syntax. It also renames the existing Walk function into Crawl, and marks it as a deprecated wrapper around Inspect. (I named it "Crawl" because it's less functional than "Walk"... get it??) There aren't that many callers to Crawl, so we can probably remove it in the future. But it doesn't seem pressing, and I'm more concerned about the risk of forgetting to invert a bool condition somewhere. Change-Id: Ib2fb275873a1d1a730249c9cb584864cb6ec370e Reviewed-on: https://go-review.googlesource.com/c/go/+/330429 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-06-11[dev.typeparams] cmd/compile: add "check" field to noder.gcimportsMatthew Dempsky
The unified IR importer needs access to the *types2.Checker instance to lazily construct objects and types. Eventually, maybe the types2.Importer API can be extended to add the Checker as another parameter (or more likely something like an ImportConfig struct), but right now we can handle this ourselves as long as we forgo the types2.(*Config).Check convenience wrapper. Updates #46449. Change-Id: I89c41d5d47c224a58841247cd236cd9f701a23a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/327053 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-06-03[dev.typeparams] cmd/compile/internal/types2: add Config.AllowTypeLists to ↵Robert Griesemer
control type list handling Eventually the flag should not be set anymore, but we set it in the compiler until all tests have been converted. Also, convert some more types2 tests to use the type set notation. Change-Id: I616599a3473451ab75d67272016b2bd3de6835af Reviewed-on: https://go-review.googlesource.com/c/go/+/324571 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-06-02[dev.typeparams] cmd/compile: add dictionary argument to generic functionsKeith Randall
When converting from a generic function to a concrete implementation, add a dictionary argument to the generic function (both an actual argument at each callsite, and a formal argument of each implementation). The dictionary argument comes before all other arguments (including any receiver). The dictionary argument is checked for validity, but is otherwise unused. Subsequent CLs will start using the dictionary for, e.g., converting a value of generic type to interface{}. Import/export required adding support for LINKSYMOFFSET, which is used by the dictionary checking code. Change-Id: I16a7a8d23c7bd6a897e0da87c69f273be9103bd7 Reviewed-on: https://go-review.googlesource.com/c/go/+/323272 Trust: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-06-01[dev.typeparams] cmd/compile: refactor noder/irgen helpersMatthew Dempsky
This CL refactors the code for invoking the types2 checker and for validating //go:embed directives to be easier to reuse separately. No functional change. Change-Id: I706f4ea4a26b1f1d2f4064befcc0777a1067383d Reviewed-on: https://go-review.googlesource.com/c/go/+/323310 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com> Trust: Matthew Dempsky <mdempsky@google.com>
2021-05-27[dev.typeparams] cmd/compile/internal/noder: refactor irgen import handlingMatthew Dempsky
Rather than re-parsing and re-resolving the import path string, use the PkgName object provided by types2 to determine what package path it refers to. Also, decompose importfile into smaller functions, so that we can directly pass the already-resolved package path to the importer. Finally, switch to simply using height as calculated by types2 rather than redoing the calculations. Change-Id: I3338f4e68387b2835b2e58d6df65d740d6a648cb Reviewed-on: https://go-review.googlesource.com/c/go/+/323309 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com> Trust: Dan Scales <danscales@google.com> Trust: Matthew Dempsky <mdempsky@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-19[dev.typeparams] cmd/compile/internal/types2: implement package heightMatthew Dempsky
This CL extends types2 with package height information, styled after the way it works already in cmd/compile: - A new NewPackageHeight entry point for constructing packages with explicit height information, and a corresponding Height accessor method. - The types2 importer is updated to provide package height for imported packages. - The types2 type checker sets height based on imported packages. - Adds an assertion to irgen to verify that types1 and types2 calculated the same height for the source package. - Func.less's ordering incorporates package height to match types.Sym.less and is generalized to object.less. - sortTypes (used for sorting embedded types) now sorts defined types using object.less as well. Change-Id: Id4dbbb627aef405cc7438d611cbdd5a5bd97fc96 Reviewed-on: https://go-review.googlesource.com/c/go/+/321231 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-07cmd/compile/internal/types2: remove Config.InferFromConstraints flagRobert Griesemer
Constraint type inference is part of the proposed language. Use an internal flag to control the feayure for debugging. Change-Id: I7a9eaee92b5ffc23c25d9e68a729acc0d705e879 Reviewed-on: https://go-review.googlesource.com/c/go/+/306770 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-03-10cmd/compile/internal/types2: better error reporting framework (starting point)Robert Griesemer
Until now, errors which came with additional details (e.g., a declaration cycle error followed by the list of objects involved in the cycle, one per line) were reported as an ordinary error followed by "secondary" errors, with the secondary errors marked as such by having a tab-indented error message. This approach often required clients to filter these secondary errors (as they are not new errors, they are just clarifying a previously reported error). This CL introduces a new internal error_ type which permits accumulating various error information that may then be reported as a single error. Change-Id: I25b2f094facd37e12737e517f7ef8853d465ff77 Reviewed-on: https://go-review.googlesource.com/c/go/+/296689 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-03-09cmd/compile: get instantiated generic types working with interfacesDan Scales
Get instantiatiated generic types working with interfaces, including typechecking assignments to interfaces and instantiating all the methods properly. To get it all working, this change includes: - Add support for substituting in interfaces in subster.typ() - Fill in the info for the methods for all instantiated generic types, so those methods will be available for later typechecking (by the old typechecker) when assigning an instantiated generic type to an interface. We also want those methods available so we have the list when we want to instantiate all methods of an instantiated type. We have both for instantiated types encountered during the initial noder phase, and for instantiated types created during stenciling of a function/method. - When we first create a fully-instantiated generic type (whether during initial noder2 pass or while instantiating a method/function), add it to a list so that all of its methods will also be instantiated. This is needed so that an instantiated type can be assigned to an interface. - Properly substitute type names in the names of instantiated methods. - New accessor methods for types.Type.RParam. - To deal with generic types which are empty structs (or just don't use their type params anywhere), we want to set HasTParam if a named type has any type params that are not fully instantiated, even if the type param is not used in the type. - In subst.typ() and elsewhere, always set sym.Def for a new forwarding type we are creating, so we always create a single unique type for each generic type instantiation. This handles recursion within a type, and also recursive relationships across many types or methods. We remove the seen[] hashtable, which was serving the same purpose, but for subst.typ() only. We now handle all kinds of recursive types. - We don't seem to need to force types.CheckSize() on created/substituted generic types anymore, so commented out for now. - Add an RParams accessor to types2.Signature, and also a new exported types2.AsSignature() function. Change-Id: If6c5dd98427b20bfe9de3379cc16f83df9c9b632 Reviewed-on: https://go-review.googlesource.com/c/go/+/298449 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-04cmd/compile: make check2 gracefully exit if it reported errorsCuong Manh Le
Otherwise, if -d=panic was set, check2 will treat already reported error as internal compiler error. For #43311 Fixes #44445 Change-Id: I5dbe06334666df21d9107396b9dcfdd905aa1e44 Reviewed-on: https://go-review.googlesource.com/c/go/+/294850 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
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-05[dev.typeparams] cmd/compile: add stenciling of simple generic functionsDan Scales
Allow full compilation and running of simple programs with generic functions by stenciling on the fly the needed generic functions. Deal with some simple derived types based on type params. Include a few new typeparam tests min.go and add.go which involve fully compiling and running simple generic code. Change-Id: Ifc2a64ecacdbd860faaeee800e2ef49ffef9df5e Reviewed-on: https://go-review.googlesource.com/c/go/+/289630 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-04[dev.typeparams] cmd/compile: pass -lang flag value to new type checkerRobert Griesemer
This enables another test. Change-Id: I80763b97d939e225158a083299b2e0d189268bc7 Reviewed-on: https://go-review.googlesource.com/c/go/+/289569 Trust: Robert Griesemer <gri@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com>
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-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-22[dev.typeparams] cmd/compile/internal/types2: adjust errors in branch ↵Robert Griesemer
checking code, fix a bug The types2.Config.IgnoreBranches flag mistakenly excluded a set of label-unrelated branch checks. After fixing this and also adjusting some error messages to match the existing compiler errors, more errorcheck tests pass now with the -G option. Renamed IngnoreBranches to IgnoreLabels since its controlling label checks, not all branch statement (such as continue, etc) checks. Change-Id: I0819f56eb132ce76c9a9628d8942af756691065a Reviewed-on: https://go-review.googlesource.com/c/go/+/285652 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@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-19[dev.typeparams] cmd/compile: cache mapped types during irgenMatthew Dempsky
If we see the exact same types2.Type a second time, we can map it to the same *types.Type instance. Not strictly necessary, but reduces memory usage and plays better with the rest of the compiler given the current state of things. Change-Id: I53686d072c7c7834b0c97417bc8d5f2cd24572b2 Reviewed-on: https://go-review.googlesource.com/c/go/+/284692 Trust: Matthew Dempsky <mdempsky@google.com> 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>