aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/expr.go
AgeCommit message (Collapse)Author
2023-01-20all: fix typos in go file commentsMarcel Meyer
This is the second round to look for spelling mistakes. This time the manual sifting of the result list was made easier by filtering out capitalized and camelcase words. grep -r --include '*.go' -E '^// .*$' . | aspell list | grep -E -x '[A-Za-z]{1}[a-z]*' | sort | uniq This PR will be imported into Gerrit with the title and first comment (this text) used to generate the subject and body of the Gerrit change. Change-Id: Ie8a2092aaa7e1f051aa90f03dbaf2b9aaf5664a9 GitHub-Last-Rev: fc2bd6e0c51652f13a7588980f1408af8e6080f5 GitHub-Pull-Request: golang/go#57737 Reviewed-on: https://go-review.googlesource.com/c/go/+/461595 Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2022-09-27cmd/compile: abstract type type+value obtained from types2Keith Randall
In preparation for encoding it in a more efficient way. Change-Id: I299dd2befc3d07107a1b7b49225bbb9f2e48a343 Reviewed-on: https://go-review.googlesource.com/c/go/+/432896 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-07-22[dev.unified] cmd/compile: make Unified IR always writes concrete type for ↵Cuong Manh Le
const exprs So we don't have to depend on typecheck pass to fixup the concrete type for some constant expressions. Previously, the problem won't show up, until CL 418475 sent, which removes an un-necessary type conversion in "append(a, b...) to help the optimization kicks in. For #53888 Change-Id: Idaecd38b7abbaa3ad5b00ff3b1fb0fd8bbeb6726 Reviewed-on: https://go-review.googlesource.com/c/go/+/418514 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-05-05cmd/compile: change ir.InstExpr.Targs from Node to NtypeMatthew Dempsky
Type arguments are always type expressions, which are semantically represented by Ntype. In fact, the slice should probably just be []*types.Type instead, and that would remove a lot of ir.TypeNode wrapping/unwrapping. But this lead to issues within the stenciling code, and I can't immediately make sense why. Change-Id: Ib944db30e4d21284bc2d8d954b68ecb70b4205a9 Reviewed-on: https://go-review.googlesource.com/c/go/+/403843 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2022-04-07cmd/compile: adjust types2 shift check to match go/types (cleanup)Robert Griesemer
With this change, the shift checking code matches the corresponding go/types code, but for the differences in the internal error reporting, and call of check.overflow. The change leads to the recording of an untyped int value if the RHS of a non-constant shift is an untyped integer value. Adjust the type in the compiler's irgen accordingly. Add test/shift3.go to verify behavior. Change-Id: I20386fcb1d5c48becffdc2203081fb70c08b282d Reviewed-on: https://go-review.googlesource.com/c/go/+/398236 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2022-03-17cmd/compile: remove typecheckdef and Name.WalkdefMatthew Dempsky
The only remaining use for typecheckdef after CL 393256 is to typecheck the ONAME node that represents function names, so we might as well just move that code into tcFunc instead. Updates #51691. Change-Id: Icbca51d4b0fb33c90faa95f16254c7171b171d8a Reviewed-on: https://go-review.googlesource.com/c/go/+/393367 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-02-24cmd/compile: delay all call transforms if in a generic functionDan Scales
We changed to delaying all transforms of generic functions, since there are so many complicated situations where type params can be used. We missed changing so that all Call expressions(not just some) are delayed if in a generic function. This changes to delaying all transforms on calls in generic functions. Had to convert Call() to g.callExpr() (so we can access g.delayTransform()). By always delaying transforms on calls in generic functions, we actually simplify the code a bit both in g.CallExpr() and stencil.go. Fixes #51236 Change-Id: I0342c7995254082c4baf709b0b92a06ec14425e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/386220 Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-02-09go/types, types2: rename structuralType/String to coreType/StringRobert Griesemer
This is a pure rename of the respective Go functions/methods with corresponding adjustments to error messages and tests. A couple of comments were manually rephrased. With this change, the implementation and error messages match the latest spec. No functionality change. Change-Id: Iaa92a08b64756356fb2c5abdaca5c943c9105c96 Reviewed-on: https://go-review.googlesource.com/c/go/+/384618 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2022-01-27go/types, cmd/compile: fix composite literal structural typingMatthew Dempsky
For a composite literal expression like []T{{f: 1}}, we allow T to be a pointer to struct type, so it's consistent to allow T to also be a type parameter whose structural type is a pointer to struct type. Fixes #50833. Change-Id: Ib0781ec4a4f327c875ea25b97740ff2c0c86b916 Reviewed-on: https://go-review.googlesource.com/c/go/+/381075 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-11-10cmd/compile/internal/types2: move some functions into different files (cleanup)Robert Griesemer
- move structuralType/structuralString into type.go - move functions exported for the compiler into compilersupport.go - updated/added comments - removed AsNamed and AsInterface - not needed by compiler No semantic changes. Change-Id: Ia454a49edafd627c2a25b0b71db4aa93ddd7f1f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/362995 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-11-02cmd/compile: remove TODO that is no longer relevantDan Scales
types2 methods are now sorted in the same way as types1, so this TODO is no longer needed. (Comment change only). Change-Id: Ic975ce001a5d54f15381a9cb7b6969dff795e3b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/360856 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-10-29cmd/compile: use Structure() to get single underlying type of typeparam.Dan Scales
Use types2.Structure() to get single underlying type of typeparams, to handle some unusual cases where a type param is constrained to a single underlying struct or map type. Fixes #48538 Change-Id: I289fb7b31d489f7586f2b04aeb1df74e15a9f965 Reviewed-on: https://go-review.googlesource.com/c/go/+/359335 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-10-08cmd/compile: allow delaying of transformCompLit, new transformAddrDan Scales
For this unusual case, where a constraint specifies exactly one type, we can have a COMPLIT expression with a type that is/has typeparams. Therefore, we add code to delay transformCompLit for generic functions. We also need to break out transformAddr (which corresponds to tcAddr), and added code for delaying it as well. Also, we now need to export generic functions containing untransformed OCOMPLIT and OKEY nodes, so added support for that in iexport.go/iimport.go. Untransformed OKEY nodes include an ir.Ident/ONONAME which we can now export. Had to adjust some code/asserts in transformCompLit(), since we may now be transforming an OCOMPLIT from an imported generic function (i.e. from a non-local package). Fixes #48537 Change-Id: I09e1b3bd08b4e013c0b098b8a25d082efa1fef51 Reviewed-on: https://go-review.googlesource.com/c/go/+/354354 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-09-28cmd/compile/internal/types2: record all instances, not just inferred instancesRobert Griesemer
This is a port of CL 349629 from go/types to types2, adjusted to make it work for types2. It also includes the necessary compiler changes, provided by mdempsky. Change-Id: If8de174cee9c69df0d0642fcec1ee7622b7c3852 Reviewed-on: https://go-review.googlesource.com/c/go/+/351455 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: Robert Findley <rfindley@google.com> Reviewed-by: Dan Scales <danscales@google.com>
2021-09-24cmd/compile: fix delayTransform conditionCuong Manh Le
The delayTransform only checks whether ir.CurFunc is generic function or not. but when compiling a non-generic closure inside a generic function, we also want to delay the transformation, which delayTransform fails to detect, since when ir.CurFunc is the closure, not the top level function. Instead, we must rely on irgen.topFuncIsGeneric field to decide whether to delay the transformation, the same logic with what is being done for not adding closure inside a generic function to g.target.Decls list. Fixes #48609 Change-Id: I5bf5592027d112fe8b19c92eb906add424c46507 Reviewed-on: https://go-review.googlesource.com/c/go/+/351855 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-09-24cmd/compile: move all usage of delayTransform out of helpers.goCuong Manh Le
So next CL will make delayTransform to become irgen's method, because the delay transform logic also depends on irgen.topFuncIsGeneric field. For #48609 Change-Id: I660ed19856bd06c3b6f4279a9184db96175dea2d Reviewed-on: https://go-review.googlesource.com/c/go/+/351854 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-09-16cmd/compile: fixing writebarrier.go for -G=3wdvxdr
This is caused by some nodes didn't carry the real line number. Noder1 wraps these node with ir.ParenExpr. To fix this issue, wraps this node like what noder1 does. Change-Id: I212cad09b93b8bf1a7adfad416d229d15711918a Reviewed-on: https://go-review.googlesource.com/c/go/+/349769 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Keith Randall <khr@golang.org>
2021-09-15cmd/compile: remove unneeded early transforms, with dictionary changeDan Scales
Now that we are computing the dictionary format on the instantiated functions, we can remove the early transformation code that was needed to create the implicit CONVIFACE nodes in the generic function. Change-Id: I1695484e7d59bccbfb757994f3e40e84288759a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/349614 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-09-09cmd/compile: fix wrong instantiated type for embedded receiverCuong Manh Le
In case of embedded field, if the receiver was fully instantiated, we must use its instantiated type, instead of passing the type params of the base receiver. Fixes #47797 Fixes #48253 Change-Id: I97613e7e669a72605137e82406f7bf5fbb629378 Reviewed-on: https://go-review.googlesource.com/c/go/+/348549 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-09-08cmd/compile/internal/types2: spell out 'Type' in type parameter APIsRobert Griesemer
This is a port of CL 348376 with the necessary adjustments in the compiler. Change-Id: Ib11ee841b194746ff231ee493aa56bf9b3a4a67f Reviewed-on: https://go-review.googlesource.com/c/go/+/348577 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-09-07cmd/compile: make sure imported instantiated types have their methods createdDan Scales
We should be putting a newly instantiated imported type in Instantiate/doInst onto the instTypeList, so its methods/dictionaries are instantiated. To do this, we needed a more general way to add a type to instTypeList, so add NeedInstType(), analogous to NeedRuntimeType(). This has the extra advantage that now all types created by the type substituter are added to instTypeList without any extra code, which was easy to forget. doInst() now correctly calls NeedInstType(). This is a bit aggressive, since a fully instantiated type in a generic function/method may never be used, if the generic method is never instantiated in the local package. But it should be fairly uncommon for a generic method to mention a fully instantiated type (but it does happen in this bug). Fixes both cases mentioned in the bug. Fixed #48185 Change-Id: I19b5012dfac17e306c8005f8595a648b0ab280d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/347909 Trust: Dan Scales <danscales@google.com> Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2021-08-30cmd/compile: fix bug with Inferred targsDan Scales
We were using the type from the wrong Node (the partially filled-in FUNCINST) rather than the original function node - which is pointed to by the OFUNCINST)) to set the final fully-substituted type of the OFUNCINST. So fixed the node reference. Also, added check so we don't do any work at all if the OFUNCINST already has all type args filled in. Added few extra cases to the test file issue48030.go, to cover fully-specified type args, partially inferred type args, and fully inferred type args. Fixes #48030 Change-Id: If9e4f2e0514d68b9d241f30c423259133932b25b Reviewed-on: https://go-review.googlesource.com/c/go/+/346229 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-08-30cmd/compile: fix error when revcType is ptr in selectorExprkorzhao
Fixes #48056 Change-Id: I13ca4caadbabf02084f66ab28b4cf0c4a3705370 Reviewed-on: https://go-review.googlesource.com/c/go/+/346049 Reviewed-by: Dan Scales <danscales@google.com> Trust: Dan Scales <danscales@google.com> Trust: Keith Randall <khr@golang.org> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org>
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-24cmd/compile/internal/types2: use TypeList in the Inferred structRobert Griesemer
This is a port of CL 343934 from go/types with the necessary adjustments to the compiler. Change-Id: I810144e6e2eb2bc8fa0d34dc206403c993cbbe7a Reviewed-on: https://go-review.googlesource.com/c/go/+/344616 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dan Scales <danscales@google.com>
2021-08-24cmd/compile/internal/types2: use a TypeList type to hold type argumentsRobert Griesemer
This is a port of CL 343933 from go/types with the necessary adjustments in the compiler. With this CL type parameters and type lists are now held in TParamList and TypeList data types which don't expose the internal representation. Change-Id: I6d60881b5db995dbc04ed3f4a96e8b5d41f83969 Reviewed-on: https://go-review.googlesource.com/c/go/+/344615 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dan Scales <danscales@google.com>
2021-08-06[dev.typeparams] cmd/compile: do transformCall with non-shape type of callDan Scales
Do the transformCall using the original types2-derived type of the call (in particular, the types of the params as non-shapes). Currently, since we were using the param types of the instantiation, we might add in interface conversions to an interface with shapes in the one case of a full-instantiated generic call. So, we do the transformCall() before installing the shaped-based instantiation. transformCall() works correctly even in the case of OCALL/FUNCINST. Fixed two related bugs: - Fixed case where we still were not correctly substituting the types for a function instantiation. - The type substituter needs to copy field flags while substituting in tstruct. Change-Id: I14e960737d6840a75846ede480e6650534ba3af3 Reviewed-on: https://go-review.googlesource.com/c/go/+/340259 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
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-29[dev.typeparams] cmd/compile: set type parameter indices when they are boundRobert Griesemer
This is a port of CL 336249 with adjustments due to slightly different handling of type parameter declaration in types2. The CL also contains adjustments to the compiler front-end. With this change it is not necessary to export type parameter indices. Filed issue #47451 so we don't forget. Change-Id: I2834f7be313fcb4763dff2a9058f1983ee6a81b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/338192 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-07-21[dev.typeparams] Fix the types of the OFUNCINST nodes in noder2Dan Scales
types2 doesn't actually give us the type of an instantiated function/method after the type args have been applied. So, do a substitution at the point that we create the OFUNCINST nodes. We also needed to add in translation of the typeparams of a function signature in the type substituter. If the type params of the function become all concrete after the substitution, then we just drop them, since the whole signature must now be concrete. Change-Id: I6116d2aa248be6924ec9e6d8516678db45aa65c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/336370 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-07-14[dev.typeparams] cmd/compile: fix escape printout bugs for -G=3Dan Scales
Call SetPos() in g.expr() so it is available for any new nodes. Print out the actual type for a composite literal in exprFmt() if available, else use Ntype if available. Seems generally useful, since the type name is always more useful than just 'composite literal'. Fixes a bunch of cases that are excluded in run.go for -G=3. Change-Id: I40b9bba88027ea4f36d419e3989e7f14891bea04 Reviewed-on: https://go-review.googlesource.com/c/go/+/334609 Trust: Dan Scales <danscales@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
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-01[dev.typeparams] cmd/compile: fix getDictionarySym for methods references, ↵Dan Scales
write out sub-dictionaries For method references (only), selectorExpr() now computes n.Selection, which is the generic method that is selected. This allows us to compute as needed the proper sub-dictionary for method reference. Also cleans up some code for distinguishing method references from references to a field that has a function value (especially in the presence of embedded fields). Change-Id: I9c5b789c15537ff48c70ca7a6444aa0420178a3a Reviewed-on: https://go-review.googlesource.com/c/go/+/332095 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-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-12[dev.typeparams] cmd/compile: simplify NewClosureFuncMatthew Dempsky
I initially made NewClosureFunc take an "outerfn *Func" parameter because I was planning on having it handle closure naming, until remembering that naming needs to wait until typecheck for noder. We don't actually need the *Func yet, just to know whether it's non-nil. So change the parameter to a bool, which simplifies callers a little. Change-Id: Ie83ee4a1ed0571ac6d3879ffd8474c6c3c1a9ff9 Reviewed-on: https://go-review.googlesource.com/c/go/+/327450 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-06-12[dev.typeparams] cmd/compile: refactor closure constructionMatthew Dempsky
typecheck.tcClosure is complicated with many code flows because all of its callers setup the closure funcs in slightly different ways. E.g., it's non-obvious who's responsible for setting the underlying func's Sym or adding it to target.Decls, or how to write new code that constructs a closure without interfering with existing code. This CL refactors everything to use three common functions in package ir: NewClosureFunc (which handle creating the Func, Name, and ClosureExpr and wiring them together), NameClosure (which generates and assigns its unique Sym), and UseClosure (which handles adding the Func to target.Decls). Most IR builders can actually name the closure right away, but the legacy noder+typecheck path may not yet know the name of the enclosing function. In particular, for methods declared with aliased receiver parameters, we need to wait until after typechecking top-level declarations to know the method's true name. So they're left anonymous until typecheck. UseClosure does relatively little work today, but it serves as a useful spot to check that the code setting up closures got it right. It may also eventually serve as an optimization point for early lifting of trivial closures, which may or may not ultimately be beneficial. Change-Id: I7da1e93c70d268f575b12d6aaeb2336eb910a6f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/327051 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-05[dev.typeparams] cmd/compile: rename (types2.Inferred.)Targs to TArgsRobert Griesemer
This is consistent with Named.TArgs. This is a straight-forward port of https://golang.org/cl/321289 plus the necessary compiler noder changes. Change-Id: I50791e5abe0d7f294293bed65cebc8dde8bf8c06 Reviewed-on: https://go-review.googlesource.com/c/go/+/325010 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
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-05-27[dev.typeparams] cmd/compile: add and use ir.RawOrigExprMatthew Dempsky
This CL adds ir.RawOrigExpr, which can be used to represent arbitrary constant expressions without needing to build and carry around an entire IR representation of the original expression. It also allows distinguishing how the constant was originally written by the user (e.g., "0xff" vs "255"). This CL then also updates irgen to make use of this functionality for expressions that were constant folded by types2. Change-Id: I41e04e228e715ae2735c357b75633a2d08ee7021 Reviewed-on: https://go-review.googlesource.com/c/go/+/323210 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> 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-12[dev.typeparams] cmd/compile: fix use of method values with stenciled methodsDan Scales
We were handling the case where an OFUNCINST node was used as a function value, but not the case when an OFUNCINST node was used as a method value. In the case of a method value, we need to create a new selector expression that references the newly stenciled method. To make this work, also needed small fix to noder2 code to properly set the Sel of a method SelectorExpr (should be just the base method name, not the full method name including the type string). This has to be correct, so that the function created by MethodValueWrapper() can be typechecked successfully. Fixes #45817 Change-Id: I7343e8a0d35fc46b44dfe4d45b77997ba6c8733e Reviewed-on: https://go-review.googlesource.com/c/go/+/319589 Reviewed-by: Keith Randall <khr@golang.org> Trust: 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-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-04-08cmd/compile: break out transformations of tcCompLit into transformCompLitDan Scales
Create transformCompLit, which does the transformations done by tcCompLit without the typechecking. This removes the final use of the old typechecker in the noder2 pass. Other changes: - Used the transformCompLit in stringstorunelit(), which creates an OCOMPLIT that needs transformation as well. - Fixed one place in transformIndex where we were still using typecheck.AssignConv, when we should be using its equivalent noder.assignconvfn. The go/test tests always run with -G=3, and I also tested that the "go test" tests continue to run correctly with -G=3. Change-Id: I4a976534ab7311cf2a5f43841026dbf7401e62b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/308529 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-30cmd/compile: handle partial type inference that doesn't require function argsDan Scales
Handle the case where types can be partially inferred for an instantiated function that is not immediately called. The key for the Inferred map is the CallExpr (if inferring types required the function arguments) or the IndexExpr (if types could be inferred without the function arguments). Added new tests for the case where the function isn't immediately called to typelist.go. Change-Id: I60f503ad67cd192da2f2002060229efd4930dc39 Reviewed-on: https://go-review.googlesource.com/c/go/+/305909 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> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-30cmd/compile: fix various small bugs related to type listsDan Scales
Fix various small bugs related to delaying transformations due to type params. Most of these relate to the need to delay a transformation when an argument of an expression or statement has a type parameter that has a structural constraint. The structural constraint implies the operation should work, but the transformation can't happen until the actual value of the type parameter is known. - delay transformations for send statements and return statements if any args/values have type params. - similarly, delay transformation of a call where the function arg has type parameters. This is mainly important for the case where the function arg is a pure type parameter, but has a structural constraint that requires it to be a function. Move the setting of n.Use to transformCall(), since we may not know how many return values there are until then, if the function arg is a type parameter. - set the type of unary expressions from the type2 type (as we do with most other expressions), since that works better with expressions with type params. - deal with these delayed transformations in subster.node() and convert the CALL checks to a switch statement. - make sure ir.CurFunc is set properly during stenciling, including closures (needed for transforming return statements during stenciling). New test file typelist.go with tests for these cases. Change-Id: I1b82f949d8cec47d906429209e846f4ebc8ec85e Reviewed-on: https://go-review.googlesource.com/c/go/+/305729 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-03-29cmd/compile: remove typechecker calls in varDecl()Dan Scales
We can now use transformAssign. The only remaining typechecker calls in the noder2 pass are for CompLitExpr nodes (OCOMPLIT). Change-Id: I25671c79cc30749767bb16f84e9f151b943eccd1 Reviewed-on: https://go-review.googlesource.com/c/go/+/305509 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-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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 10:38:50 +0000