aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/typecheck/iexport.go
AgeCommit message (Collapse)Author
2021-08-26cmd/compile: move types init code into package typesMatthew Dempsky
This moves the package types setup code from package typecheck into package types itself. This is a prereq for making types.Type more opaque, because some unit tests depend on being able to init the basic universal types. A few notable details of this CL: 1. Creating the builtin types requires being able to create the ir.Name/ir.OTYPE that represents it, but package types can't depend on package ir. So we add a callback function to handle creating the ir.Name. 2. This CL moves ir.Pkgs.Unsafe to types.UnsafePkg. Package unsafe is part of the language, not like the other ir.Pkgs packages that are purely implementation details. 3. This CL also moves typecheck.FakeRecv to types.FakeRecv, addressing an outstanding TODO. Change-Id: I64de04ce82fbcd1bb59f547e2eea3cda52d89429 Reviewed-on: https://go-review.googlesource.com/c/go/+/345474 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-08-18cmd/compile: only sort methods/interfaces during export for -d=unifiedquirksMatthew Dempsky
These sorts are only important for 'toolstash -cmp' testing of unified IR against -G=0 mode, but they were added before I added -d=unifiedquirks to allow altering small "don't care" output details like this. This CL should help mitigate issues with #44195 until package objectpath is updated and deployed. Change-Id: Ia3dcf359481ff7abad5ddfca8e673fd2bb30ae01 Reviewed-on: https://go-review.googlesource.com/c/go/+/343390 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-08-11[dev.typeparams] cmd/compile: change export version to 1.17 for testingDan Scales
This is a temporary change. We will revert this back before the 1.18 release. We make this change now to simplify testing, since a lot of tools will break on the new export version. Updates #47654. Change-Id: I0650fa753bb11229c71254d779dd61b5c1af9cdf Reviewed-on: https://go-review.googlesource.com/c/go/+/341211 Trust: Dan Scales <danscales@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-08-10[dev.typeparams] cmd/compile: keep export format unchanged if no type params ↵Dan Scales
are exported Added new export tags 'G' and 'U' to export parameterized functions/methods and parameterized types respectively. This has the advantage that the Go 1.18 format remains backward-compatible with the Go 1.17 format if no type parameters are exported. Change-Id: I9dba8faaa65609eb3f9c693bd0c79daee98bd865 Reviewed-on: https://go-review.googlesource.com/c/go/+/340989 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> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-08-07[dev.typeparams] cmd/compile: don't export/import type parameter indices anymoreDan Scales
types2 now determines type parameter indices lazily, so we don't need them just as we are importing. We set them in types1 as we are importing the type param list itself. type param indices are not strongly needed in types1 - we only use them in one place which could be rewritten. But I kept them in analogy to types2 (TypeParam.Index). Fixes #47451 Change-Id: I30631f95c45a259354eaf7ec5194f71e799eb358 Reviewed-on: https://go-review.googlesource.com/c/go/+/340532 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-08-06[dev.typeparams] cmd/compile: swap export order of union term components ↵Robert Griesemer
(cleanup) Export a term as a pair (tilde, type) rather than (type, tilde) to match the new Union/Term API. Change-Id: I221c09c2c746ae19fbae0c970ffb26fa7a8ac736 Reviewed-on: https://go-review.googlesource.com/c/go/+/340251 Trust: Robert Griesemer <gri@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-07-24[dev.typeparams] cmd/compile: introduce OCONVIDATA opKeith Randall
This operation computes just the data field needed to put its argument into an interface. Used by generics because we produce the type field of an interface using dictionaries (instead of statically). With this operation defined, we can now assert that shape types are never marked as used in interfaces (the only previous use was IDATA(CONVIFACE(t))). Change-Id: Idb1eb5f3b238285cb99413d382599c0621b7681a Reviewed-on: https://go-review.googlesource.com/c/go/+/337109 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-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-07-12[dev.typeparams] Add optional sub-dict entry for typeparam bound callsDan Scales
In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-07[dev.typeparams] cmd/compile: fix windows longtest builderMatthew Dempsky
CL 332469 broke the Windows longtest builders, because it changed the names assigned to autotmp variables that end up in export data. The naming of autotmps doesn't actually matter, so instead we can just hack iexport to write out "$autotmp" as a magic marker, and let the reader replace it with an appropriate unique name. This is a little hacky, but so is iexport's handling of autotmps already, and this should also go away eventually with unified IR. Change-Id: Ic17395337c745b66b9d63ee566299290214e6273 Reviewed-on: https://go-review.googlesource.com/c/go/+/333089 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-07-07[dev.typeparams] cmd/compile: handle the (*T).M method expression with ↵Dan Scales
dictionaries The (*T).M method expression is where M is a value method, but the type (*T) is a pointer to the main type. In this case, after following any embedded fields, we need to add an extra star operator when using the receiver arg in the closure call. Thanks to Cuong for finding/pointing out an example for this case (typeparam/mdempsky/14.go) This example also shows that we now need the ability to export/import OEFACE and OIDATA, which I added. Change-Id: Ida0f81ce757fff78fec6276c60052ed71d207454 Reviewed-on: https://go-review.googlesource.com/c/go/+/333014 Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03[dev.typeparams] cmd/compile: remove ir.CallUseMatthew Dempsky
Unneeded after the previous CL changed inlining to leave OINLCALL nodes in place. Change-Id: I9af09a86a21caa51a1117b3de17d7312dd702600 Reviewed-on: https://go-review.googlesource.com/c/go/+/332650 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Matthew Dempsky <mdempsky@google.com>
2021-06-27[dev.typeparams] cmd/compile: rename OCALLPART to OMETHVALUECuong Manh Le
Go spec call them "method values", not "partial calls". Note that we use "OMETHVALUE" (as opposed to "OMETHODVALUE") to be consistent with "OMETHEXPR". Change-Id: I1efd985d4b567a1b4b20aeb603eb82db579edbd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/330837 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-06-07[dev.typeparams] cmd/compile: introduce IsTypeParam() helperKeith Randall
better than Kind() == types.TTYPEPARAM Change-Id: I4f35a177cd0cda3be615a92b7b2af1b5a60a3bbc Reviewed-on: https://go-review.googlesource.com/c/go/+/325410 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-05[dev.typeparams] cmd/compile: refactor export writingMatthew Dempsky
This CL reorganizes export writing in preparation for unified IR: 1. It moves dumpexport into noder as noder.WriteExports so that it can be extended to include unified IR's export data. 2. Adds an "extensions" flag to typecheck.WriteExports to control whether the compiler-only extension data (e.g., function bodies and linker symbol info) is included in the exports. 3. It moves the gc.exporter type into typecheck and renames it to "crawler". The type originated as the implementation of the (pre-iexport) binary exporter, but since the removal of bexport it's been relegated to simply crawling the exported functions/bodies graph to identify which inline bodies need to be included. 4. It changes inline.Inline_Flood into the method crawler.markInlBody. Inline_Flood doesn't actually have anything to do with the rest of inlining; its current name and location are just historical quirks. Passes toolstash -cmp. Change-Id: I6445e2de9d3ce500a3aded5a8e20b09f46d23dbc Reviewed-on: https://go-review.googlesource.com/c/go/+/325212 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-06-04[dev.typeparams] cmd/compile: point StructKeyExpr at the types.FieldMatthew Dempsky
When constructing struct literals, importers need a way to specify precisely which field to initialize without worrying about visibility or those fields being blank. (A blank field doesn't actually need to be initialized, but the expression needs to be evaluated still, and with the right order-of-operations.) This CL changes StructKeyExpr's Field field to point directly to the corresponding types.Field, rather than merely holding a copy of its Sym and Offset. This is akin to past changes to add SelectorExpr.Selection. Change-Id: I95b72b1788f73206fcebc22b456cf6b1186db6a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/325031 Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-06-04[dev.typeparams] cmd/compile: allow inlining in instantiated functionsDan Scales
Change markType to scan generic types and methods, so that inlineable functions inside generic functions/methods will be properly marked for export, which means inlining inside instantiated functions will work correctly. Also, fix handling of closures for instantiated functions. Some code needs to be adjusted, since instantiated functions/methods are compiled as if in the package of the source generic function/type, rather than in the local package. When we create the closure struct, we want to make sure that the .F field has the same package as the other fields for the closure variables. Also, we need to disable a check in tcCompLit() when being done for an instantiated function, since fields of the closure struct will be from the source package, not the local package. Re-enabled part of the orderedmapsimp test that was disabled because of these issues. Change-Id: Ic4dba8917da0a36b17c0bdb69d6d6edfdf14104a Reviewed-on: https://go-review.googlesource.com/c/go/+/324331 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-06-04[dev.typeparams] cmd/compile: export/import of recursive generic types.Dan Scales
Deal with export/import of recursive generic types. This includes typeparams which have bounds that reference the typeparam. There are three main changes: - Change export/import of typeparams to have an implicit "declaration" (doDecl). We need to do a declaration of typeparams (via the typeparam's package and unique name), because it may be referenced within its bound during its own definition. - We delay most of the processing of the Instantiate call until we finish the creation of the top-most type (similar to the way we delay CheckSize). This is because we can't do the full instantiation properly until the base type is fully defined (with methods). The functions delayDoInst() and resumeDoInst() delay and resume the processing of the instantiations. - To do the full needed type substitutions for type instantiations during import, I had to separate out the type subster in stencil.go and move it to subr.go in the typecheck package. The subster in stencil.go now does node substitution and makes use of the type subster to do type substitutions. Notable other changes: - In types/builtins.go, put the newly defined typeparam for a union type (related to use of real/imag, etc.) in the current package, rather than the builtin package, so exports/imports work properly. - In types2, allowed NewTypeParam() to be called with a nil bound, and allow setting the bound later. (Needed to import a typeparam whose bound refers to the typeparam itself.) - During import of typeparams in types2 (importer/import.go), we need to keep an index of the typeparams by their package and unique name (with id). Use a new map typParamIndex[] for that. Again, this is needed to deal with typeparams whose bounds refer to the typeparam itself. - Added several new tests absdiffimp.go and orderedmapsimp.go. Some of the orderemapsimp tests are commented out for now, because there are some issues with closures inside instantiations (relating to unexported names of closure structs). - Renamed some typeparams in test value.go to make them all T (to make typeparam uniqueness is working fine). Change-Id: Ib47ed9471c19ee8e9fbb34e8506907dad3021e5a Reviewed-on: https://go-review.googlesource.com/c/go/+/323029 Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-06-02[dev.typeparams] cmd/compile: fix export/import of constants with typeparam typeDan Scales
A constant will have a TYPEPARAM type if it appears in a place where it must match that typeparam type (e.g. in a binary operation with a variable of that typeparam type). If so, then we must write out its actual constant kind as well, so its constant val can be read in properly during import. Fixed some export/import tests which were casting some untyped constants to avoid this problem. Change-Id: I285ad8f1c8febbe526769c96e6b27acbd23050f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/324189 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.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-05-27[dev.typeparams] cmd/compile/internal/inline: refactor mkinlcallMatthew Dempsky
This CL refactors mkinlcall by extracting the core InlinedCallExpr construction code into a new "oldInline" function, and adds a new "NewInline" hook point that can be overriden with a new inliner implementation that only needs to worry about the details of constructing the InlinedCallExpr. It also moves the delayretvars optimization check into CanInline, so it's performed just once per inlinable function rather than once for each inlined call. Finally, it skips printing the function body about to be inlined (and updates the couple of regress tests that expected this output). We already report the inline body as it was saved, and this diagnostic is only applicable to the current inliner, which clones existing function body instances. In the unified IR inliner, we'll directly construct inline bodies from the serialized representation. Change-Id: Ibdbe617da83c07665dcbda402cc8d4d4431dde2f Reviewed-on: https://go-review.googlesource.com/c/go/+/323290 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-27[dev.typeparams] cmd/compile: tweaks to match types2Matthew Dempsky
This CL makes a handful of changes to either bring existing compiler output consistent with what types2 produces or to make it easier to reproduce with types2: 1. The position for embedded fields is corrected to the position of the syntax.Field, rather than the syntax.Type. 2. Methods and embedded types are sorted in export data the same way that types2 sorts them. 3. Don't write out position information for OLITERALs that don't have their own position (i.e., references to named constants). Change-Id: Ic3979215ae9ef280cfbba7b44c236e03fc12a2ef Reviewed-on: https://go-review.googlesource.com/c/go/+/323209 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Dan Scales <danscales@google.com> Trust: Matthew Dempsky <mdempsky@google.com>
2021-05-27[dev.typeparams] cmd/compile: use old export format if not compiling with ↵Dan Scales
generics Write out export data with the old export format (iexportVersionPosCol) if not compiling with generics (-G=0, the default value). This helps ensure we don't break tests involving x/tools/go/gcexportdata (since we can't modify that tool yet to use the new format). Change-Id: I5f9bce44ed1e0696fc65fead6bab9e30de88461d Reviewed-on: https://go-review.googlesource.com/c/go/+/323189 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org>
2021-05-26[dev.typeparams] cmd/compile: adding union support in types1Dan Scales
Add union support in types1, and allow exporting of unions, and importing unions back into types1 and types2. Added new test mincheck.go/mincheck.dir that tests that type lists (type sets) are correctly exported/imported, so that types2 gives correct errors that an instantiation doesn't fit the type list in the type param constraint. Change-Id: I8041c6c79289c870a95ed5a1b10e4c1c16985b12 Reviewed-on: https://go-review.googlesource.com/c/go/+/322609 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-24[dev.typeparams] Don't check typecheck(3) on transform, so no need to ↵Dan Scales
export/import it We have a value typecheck(3) that indicates that a node in a generic function still needs transformation (via the functions in transform.go). But it is not very desirable to export/import the value of typecheck(3). So, I changed the stenciling code to just try to transform all relevant node types during node copy. Almost all tranform functions were already idempotent. I only had to add an extra if check before calling transformAssign() in the OAS case. We still use the typecheck(3) in noder to determine when higher-nodes have to delay transformation because one or more of their args are delaying transformation. Added new test mapsimp.go that required these tranformations after import. As an additional change, export/import of OINDEX requires exporting the type using w.exoticType() rather than w.typ(), in order to handle generic functions. Since generic functions can have pre-transform operations, the index operation can have a tuple type (multiple return from a map lookup). Added printing of imported function bodies in -W=3 debug mode. Change-Id: I220e2428dc5f2741e91db146f075eb5b6045f451 Reviewed-on: https://go-review.googlesource.com/c/go/+/322191 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-05-21[dev.typeparams] cmd/compile: fixing import of comm clauses/closures in ↵Dan Scales
generic functions Improvements: - Fix export/import of the default case of a select statement (was not dealing with nil Comm case) - Set properly the name of closure functions in imported generic functions Added new test exporting/importing a reasonably large channel package, chansimp.go. Change-Id: If2ee12bd749e5df415f48ec4b629a2fa68a79dcb Reviewed-on: https://go-review.googlesource.com/c/go/+/321734 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-05-21[dev.typeparams] cmd/compile: add import/export of calls to builtin functionsDan Scales
For generic functions, we have to leave the builtins in OCALL form, rather than transform to specific ops, since we don't know the exact types involved. Allow export/import of builtins in OCALL form. Added new export/import test mapimp.go. Change-Id: I571f8eeaa13b4f69389dbdb9afb6cc61924b9bf2 Reviewed-on: https://go-review.googlesource.com/c/go/+/321750 Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-05-21[dev.typeparams] cmd/compile: export OFUNCINST and OSELRECV2 nodes (for ↵Dan Scales
generic functions) Added new test typeparam/factimp.go and changed a bunch of other tests to test exporting more generic functions and types. Change-Id: I573d75431cc92482f8f908695cfbc8e84dbb36d2 Reviewed-on: https://go-review.googlesource.com/c/go/+/321749 Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-05-21[dev.typeparams] cmd/compile: move to new export version, keep reading ↵Dan Scales
previous version I added constants for the previous export versions, and for the final generics export version. I also added a const for the current export version. We can increment the current export version for unstable changes in dev.typeparams, and eventally set it back to the generics version (2) before release. Added the same constants in typecheck/iexport.go, importer/iimport.go, and gcimporter/iimport.go, must be kept in sync. Put in the needed conditionals to be able to read old versions. Added new export/import test listimp.dir. Change-Id: I166d17d943e07951aa752562e952b067704aeeca Reviewed-on: https://go-review.googlesource.com/c/go/+/319931 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-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-05-02cmd/compile: implement unsafe.Add and unsafe.SliceMatthew Dempsky
Updates #19367. Updates #40481. Change-Id: Iabd2afdd0d520e5d68fd9e6dedd013335a4b3886 Reviewed-on: https://go-review.googlesource.com/c/go/+/312214 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-04-27cmd/compile: tighten exportWriter.qualifiedIdent signatureMatthew Dempsky
It always takes an *ir.Name and would panic given anything else anyway, so tighten the signature to match. Change-Id: I44fec5c5cc6d7f0b9c59eb91c9f9633137485360 Reviewed-on: https://go-review.googlesource.com/c/go/+/314009 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-21cmd/compile: allow export/import OSLICE2ARRPTRCuong Manh Le
Updates #395 Fixes #45665 Change-Id: Iaf053c0439a573e9193d40942fbdb22ac3b4d3bb Reviewed-on: https://go-review.googlesource.com/c/go/+/312070 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-20cmd/compile: separate out parameter and field export encodingKeith Randall
These two types of *types.Field encode different concepts, so we encode them separately (and ignore fields that don't matter for each concept). Change-Id: I9d1608413949a109f12a3ebd52cd7af5f476e415 Reviewed-on: https://go-review.googlesource.com/c/go/+/312130 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-20cmd/compile: pass struct field note information along in exported infoKeith Randall
This is needed to make field tracking work correctly. Change-Id: I0c3452a48d6f36862f6ee8aacc001813866c0ad4 Reviewed-on: https://go-review.googlesource.com/c/go/+/312069 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-14cmd/compile: fix importing of method expressionsKeith Randall
For OMETHEXPR, the Name in the Selection needs to be properly linked up to the method declaration. Use the same code we already have for ODOTMETH and OCALLPART to do that. Fixes #45503 Change-Id: I7d6f886d606bae6faad8c104f50c177f871d41c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/309831 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> 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-04-10cmd/compile: include typecheck information in export/importKeith Randall
Include type information on exported function bodies, so that the importer does not have to re-typecheck the body. This involves including type information in the encoded output, as well as avoiding some of the opcode rewriting and other changes that the old exporter did assuming there would be a re-typechecking pass. This CL could be considered a cleanup, but is more important than that because it is an enabling change for generics. Without this CL, we'd have to upgrade the current typechecker to understand generics. With this CL, the current typechecker can mostly go away in favor of the types2 typechecker. For now, inlining of functions that contain closures is turned off. We will hopefully resolve this before freeze. Object files are only 0.07% bigger. Change-Id: I85c9da09f66bfdc910dc3e26abb2613a1831634d Reviewed-on: https://go-review.googlesource.com/c/go/+/301291 Trust: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com>
2021-03-29cmd/compile: restructure ABI wrapper generation, export ABIAustin Clements
This CL restructures how we track function ABIs and generate ABI wrappers in the compiler and adds import/export of ABIs across package boundaries. Currently, we start by tracking definition and referencing ABIs in two global maps and eventually move some of this information into the LSyms for functions. This complicates a lot of the existing code for handling wrappers and makes it particularly hard to export ABI information across packages. This change is built around instead recording this information on the ir.Func. First, this change replaces the global ABI def/ref maps with a type, which makes the data flow and lifetime of this information clear in gc.Main. These are populated during flag parsing. Then, early in the front-end, we loop over all ir.Funcs to 1. attach ABI def/ref information to the ir.Funcs and 2. create new ir.Funcs for ABI wrappers. Step 1 is slightly subtle because the information is keyed by linker symbol names, so we can't simply look things up in the compiler's regular symbol table. By generating ABI wrappers early in the front-end, we decouple this step from LSym creation, which makes LSym creation much simpler (like it was before ABI wrappers). In particular, LSyms for wrappers are now created at the same time as all other functions instead of by makeABIWrapper, which means we're back to the simpler, old situation where InitLSym was the only thing responsible for constructing function LSyms. Hence, we can restore the check that InitLSym is called exactly once per function. Attaching the ABI information to the ir.Func has several follow-on benefits: 1. It's now easy to include in the export info. This enables direct cross-package cross-ABI calls, which are important for the performance of calling various hot assembly functions (e.g., internal/bytealg.*). This was really the point of this whole change. 2. Since all Funcs, including wrappers, now record their definition ABI, callTargetLSym no longer needs to distinguish wrappers from non-wrappers, so it's now nearly trivial (it would be completely trivial except that it has to work around a handful of cases where ir.Name.Func is nil). The simplification of callTargetLSym has one desirable but potentially surprising side-effect: the compiler will now generate direct calls to the definition ABI even when ABI wrappers are turned off. This is almost completely unnoticeable except that cmd/internal/obj/wasm looks for the call from runtime.deferreturn (defined in Go) to runtime.jmpdefer (defined in assembly) to compile is specially. That now looks like a direct call to ABI0 rather than going through the ABIInternal alias. While we're in here, we also set up the structures to support more than just ABI0 and ABIInternal and add various additional consistency checks all around. Performance-wise, this reduces the overhead induced by wrappers from 1.24% geomean (on Sweet) to 0.52% geomean, and reduces the number of benchmarks impacts >2% from 5 to 3. It has no impact on compiler speed. Impact of wrappers before this change: name old time/op new time/op delta BiogoIgor 15.8s ± 2% 15.8s ± 1% ~ (p=0.863 n=25+25) BiogoKrishna 18.3s ± 6% 18.1s ± 7% -1.39% (p=0.015 n=25+25) BleveIndexBatch100 5.88s ± 3% 6.04s ± 6% +2.72% (p=0.000 n=25+25) BleveQuery 6.42s ± 1% 6.76s ± 1% +5.31% (p=0.000 n=24+24) CompileTemplate 245ms ± 3% 250ms ± 6% ~ (p=0.068 n=22+25) CompileUnicode 93.6ms ± 2% 93.9ms ± 5% ~ (p=0.958 n=22+25) CompileGoTypes 1.60s ± 2% 1.59s ± 2% ~ (p=0.115 n=24+24) CompileCompiler 104ms ± 4% 104ms ± 3% ~ (p=0.453 n=22+25) CompileSSA 11.0s ± 2% 11.0s ± 1% ~ (p=0.789 n=24+25) CompileFlate 153ms ± 2% 153ms ± 1% ~ (p=0.055 n=21+20) CompileGoParser 229ms ± 2% 230ms ± 2% ~ (p=0.305 n=21+22) CompileReflect 585ms ± 5% 582ms ± 3% ~ (p=0.365 n=25+25) CompileTar 211ms ± 1% 211ms ± 3% ~ (p=0.592 n=20+22) CompileXML 282ms ± 3% 281ms ± 2% ~ (p=0.937 n=22+23) CompileStdCmd 13.7s ± 3% 13.6s ± 2% ~ (p=0.700 n=25+25) FoglemanFauxGLRenderRotateBoat 8.67s ± 1% 8.78s ± 1% +1.30% (p=0.000 n=25+25) FoglemanPathTraceRenderGopherIter1 20.5s ± 2% 20.9s ± 2% +1.85% (p=0.000 n=25+25) GopherLuaKNucleotide 30.1s ± 2% 31.1s ± 2% +3.38% (p=0.000 n=25+25) MarkdownRenderXHTML 246ms ± 5% 250ms ± 1% +1.42% (p=0.002 n=25+23) Tile38WithinCircle100kmRequest 828µs ± 6% 885µs ± 6% +6.85% (p=0.000 n=23+25) Tile38IntersectsCircle100kmRequest 1.04ms ± 5% 1.10ms ± 7% +5.63% (p=0.000 n=25+25) Tile38KNearestLimit100Request 974µs ± 4% 972µs ± 4% ~ (p=0.356 n=25+24) [Geo mean] 588ms 595ms +1.24% (https://perf.golang.org/search?q=upload:20210328.5) And after this change: name old time/op new time/op delta BiogoIgor 15.9s ± 1% 15.8s ± 1% -0.48% (p=0.008 n=22+25) BiogoKrishna 18.4s ± 6% 17.8s ± 6% -3.55% (p=0.008 n=25+25) BleveIndexBatch100 5.86s ± 3% 5.97s ± 4% +1.88% (p=0.001 n=25+25) BleveQuery 6.42s ± 1% 6.75s ± 1% +5.14% (p=0.000 n=25+25) CompileTemplate 246ms ± 5% 245ms ± 2% ~ (p=0.472 n=23+23) CompileUnicode 93.7ms ± 3% 93.5ms ± 2% ~ (p=0.813 n=22+23) CompileGoTypes 1.60s ± 2% 1.60s ± 2% ~ (p=0.108 n=25+23) CompileCompiler 104ms ± 3% 104ms ± 2% ~ (p=0.845 n=23+23) CompileSSA 11.0s ± 2% 11.0s ± 2% ~ (p=0.525 n=25+25) CompileFlate 152ms ± 1% 153ms ± 2% ~ (p=0.408 n=22+22) CompileGoParser 230ms ± 1% 230ms ± 1% ~ (p=0.363 n=21+23) CompileReflect 582ms ± 3% 584ms ± 4% ~ (p=0.658 n=25+25) CompileTar 212ms ± 2% 211ms ± 2% ~ (p=0.315 n=23+24) CompileXML 282ms ± 1% 282ms ± 1% ~ (p=0.991 n=23+22) CompileStdCmd 13.6s ± 2% 13.6s ± 2% ~ (p=0.699 n=25+24) FoglemanFauxGLRenderRotateBoat 8.66s ± 1% 8.69s ± 1% +0.28% (p=0.002 n=25+24) FoglemanPathTraceRenderGopherIter1 20.5s ± 3% 20.5s ± 2% ~ (p=0.407 n=25+25) GopherLuaKNucleotide 30.1s ± 2% 31.2s ± 2% +3.82% (p=0.000 n=25+25) MarkdownRenderXHTML 246ms ± 3% 245ms ± 1% ~ (p=0.478 n=23+22) Tile38WithinCircle100kmRequest 820µs ± 4% 856µs ± 5% +4.39% (p=0.000 n=24+25) Tile38IntersectsCircle100kmRequest 1.05ms ± 6% 1.07ms ± 6% +1.91% (p=0.014 n=25+25) Tile38KNearestLimit100Request 970µs ± 4% 970µs ± 3% ~ (p=0.819 n=22+24) [Geo mean] 588ms 591ms +0.52% (https://perf.golang.org/search?q=upload:20210328.6) For #40724. Change-Id: I1c374e32d4bbc88efed062a1b360017d3642140d Reviewed-on: https://go-review.googlesource.com/c/go/+/305274 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-09cmd/compile: remove skipping of implicit operations during exportKeith Randall
We'll need to attach types to these operations, so we need to represent them in the import/export data. Some of the operations use a selector indicating a different package, so we need to provide an option to encode the package of a selector. The default selector() function can't encode that extra information, as selector's exact encoding is used by go/types. Change-Id: I4c110fe347b3d915f88a722834bc4058baea7854 Reviewed-on: https://go-review.googlesource.com/c/go/+/299771 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-03-09cmd/compile: add debugging mode for import/exportKeith Randall
Just add a simple magic number with each op, to detect when the reader gets desynchronized from the writer. Change-Id: Iac7dab7f465b0021b1d7ae31c8f8a353ac3663a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/299769 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-02-24cmd/compile: plumb abi info into ssagen/ssaDavid Chase
Plumb abi information into ssa/ssagen for plain calls and plain functions (not methods). Does not extend all the way through the compiler (yet). One test disabled because it extends far enough to break the test. Normalized all the compiler's register args TODOs to // TODO(register args) ... For #40724. Change-Id: I0173a4579f032ac3c9db3aef1749d40da5ea01ff Reviewed-on: https://go-review.googlesource.com/c/go/+/293389 Trust: David Chase <drchase@google.com> Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-01-25[dev.regabi] cmd/compile: enable rational constant arithmeticMatthew Dempsky
This allows more precision and matches types2's behavior. For backwards compatibility with gcimporter, for now we still need to write out declared constants as limited-precision floating-point values. To ensure consistent behavior of constant arithmetic whether it spans package boundaries or not, we include the full-precision rational representation in the compiler's extension section of the export data. Also, this CL simply uses the math/big.Rat.String text representation as the encoding. This is inefficient, but because it's only in the compiler's extension section, we can easily revisit this in the future. Declaring exported untyped float and complex constants isn't very common anyway. Within the standard library, only package math declares any at all, containing just 15. And those 15 are only imported a total of 12 times elsewhere in the standard library. Change-Id: I85ea23ab712e93fd3b68e52d60cbedce9be696a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/286215 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-20[dev.regabi] cmd/compile: exporting, importing, and inlining functions with ↵Dan Scales
OCLOSURE I have exporting, importing, and inlining of functions with closures working in all cases (issue #28727). all.bash runs successfully without errors. Approach: - Write out the Func type, Dcls, ClosureVars, and Body when exporting an OCLOSURE. - When importing an OCLOSURE, read in the type, dcls, closure vars, and body, and then do roughly equivalent code to (*noder).funcLit - During inlining of a closure within inlined function, create new nodes for all params and local variables (including closure variables), so they can have a new Curfn and some other field values. Must substitute not only on the Nbody of the closure, but also the Type, Cvars, and Dcl fields. Fixes #28727 Change-Id: I4da1e2567c3fa31a5121afbe82dc4e5ee32b3170 Reviewed-on: https://go-review.googlesource.com/c/go/+/283112 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Trust: Dan Scales <danscales@google.com>
2021-01-13[dev.regabi] cmd/compile: added limited //go:registerparams pragma for new ↵David Chase
ABI dev This only works for functions; if you try it with a method, it will fail. It does work for both local package and imports. For now, it tells you when it thinks it sees either a declaration or a call of such a function (this will normally be silent since no existing code uses this pragma). Note: it appears to be really darn hard to figure out if this pragma was set for a method, and the method's call site. Better ir.Node wranglers than I might be able to make headway, but it seemed unnecessary for this experiment. Change-Id: I601c2ddd124457bf6d62f714d7ac871705743c0a Reviewed-on: https://go-review.googlesource.com/c/go/+/279521 Trust: David Chase <drchase@google.com> Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org>
2021-01-12[dev.regabi] cmd/compile: stop using Vargen for import/exportMatthew Dempsky
Historically, inline function bodies were exported as plain Go source code, and symbol mangling was a convenient hack because it allowed variables to be re-imported with largely the same names as they were originally exported as. However, nowadays we use a binary format that's more easily extended, so we can simply serialize all of a function's declared objects up front, and then refer to them by index later on. This also allows us to easily report unmangled names all the time (e.g., error message from issue7921.go). Fixes #43633. Change-Id: I46c88f5a47cb921f70ab140976ba9ddce38df216 Reviewed-on: https://go-review.googlesource.com/c/go/+/283193 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-01-04[dev.regabi] cmd/compile: remove Name.Class_ accessorsMatthew Dempsky
These aren't part of the Node interface anymore, so no need to keep them around. Passes toolstash -cmp. [git-generate] cd src/cmd/compile/internal/ir : Fix one off case that causes trouble for rf. sed -i -e 's/n.SetClass(ir.PAUTO)/n.Class_ = ir.PAUTO/' ../ssa/export_test.go pkgs=$(go list . ../...) rf ' ex '"$(echo $pkgs)"' { var n *Name var c Class n.Class() -> n.Class_ n.SetClass(c) -> n.Class_ = c } rm Name.Class rm Name.SetClass mv Name.Class_ Name.Class ' Change-Id: Ifb304bf4691a8c455456aabd8aa77178d4a49500 Reviewed-on: https://go-review.googlesource.com/c/go/+/281294 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-01-04[dev.regabi] cmd/compile: fix re-export of parametersMatthew Dempsky
When exporting signature types, we include the originating package, because it's exposed via go/types's API. And as a consistency check, we ensure that the parameter names came from that same package. However, we were getting this wrong in the case of exported variables that were initialized with a method value using an imported method. In this case, when we created the method value wrapper function's type (which is reused as the variable's type if none is explicitly provided in the variable declaration), we were reusing the original (i.e., imported) parameter names, but the newly created signature type was associated with the current package instead. The correct fix here is really to preserve the original signature type's package (along with position and name for its parameters), but that's awkward to do at the moment because the DeclFunc API requires an ir representation of the function signature, whereas we only provide a way to explicitly set packages via the type constructor APIs. As an interim fix, we associate the parameters with the current package, to be consistent with the signature type's package. Fixes #43479. Change-Id: Id45a10f8cf64165c9bc7d9598f0a0ee199a5e752 Reviewed-on: https://go-review.googlesource.com/c/go/+/281292 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-01-01[dev.regabi] cmd/compile: remove idempotent Name() calls [generated]Matthew Dempsky
[git-generate] cd src/cmd/compile/internal/ir pkgs=$(grep -l -w Name ../*/*.go | xargs dirname | sort -u | grep -v '/ir$') rf ' ex . '"$(echo $pkgs)"' { var n *Name n.Name() -> n } ' Change-Id: I6bfce6417a6dba833d2f652ae212a32c11bc5ef6 Reviewed-on: https://go-review.googlesource.com/c/go/+/280972 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org>
2020-12-30[dev.regabi] cmd/compile: use *ir.Name for Decl.XCuong Manh Le
Passes toolstash -cmp. Change-Id: I505577d067eda3512f6d78618fc0eff061a71e3c Reviewed-on: https://go-review.googlesource.com/c/go/+/280732 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>