aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/stencil.go
AgeCommit message (Collapse)Author
2024-08-20cmd/compile/internal/noder: reduce clutter a bit (cosmetic changes)Robert Griesemer
- introduce index alias - inline the two short tables in stmt.go (removes a TODO) - move assert out of stencil.go and remove that file (we can always re-introduce it) Also, replace two if's with a simpler switch. Change-Id: I25c3104164574999dd9826dee6166dd8a8488908 Reviewed-on: https://go-review.googlesource.com/c/go/+/607236 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Tim King <taking@google.com>
2023-01-26cmd/compile: remove GOEXPERIMENT=nounified frontendMatthew Dempsky
This CL removes most of the code specific to the nounified frontend. To simplify review, it's a strict remove-only CL. Updates #57410. Change-Id: Ic3196570aa4286618c1d5e7fd0d0e6601a18195b Reviewed-on: https://go-review.googlesource.com/c/go/+/458620 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2022-10-03cmd/compile/internal: fix a few function names on commentscui fliter
Change-Id: If78c6d3c6183494f71f2857e496e172a789da39f GitHub-Last-Rev: 58e0b75052a92cb720371d2b3c75e1de79d79bdc GitHub-Pull-Request: golang/go#55992 Reviewed-on: https://go-review.googlesource.com/c/go/+/437517 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
2022-09-30cmd/compile/internal/noder: remove unnecessary assignment to the blank ↵cuiweixie
identifier Change-Id: I51dd087e630bf433c30d0aaaf3715b62524eb432 Reviewed-on: https://go-review.googlesource.com/c/go/+/436647 Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: xie cui <523516579@qq.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-09-19cmd/compile: skip emitting dictionaries with missing method expressionsMatthew Dempsky
The nounified frontend currently tries to construct dictionaries that correspond to invalid instantiations (i.e., instantiations T[X] where X does not satisfy the constraints specified on T's type parameter). As a consequence, we may fail to find method expressions needed by the dictionary. The real fix for this is to avoid creating those dictionaries in the first place, because they should never actually be needed at runtime. But that seems scary for a backport: we've repeatedly attempted to backport generics fixes, which have fixed one issue but introduced another. This CL is a minimally invasive solution to #54225, which avoids the ICE by instead skipping emitting the invalid dictionary. If the dictionary ends up not being needed (which I believe will always be the case), then the linker's reachability analysis will simply ignore its absence. Or worst case, if the dictionary *is* reachable somehow, we've simply turned an ICE into a link-time missing symbol failure. That's not great for user experience, but it seems like a small trade off to avoid risking breaking any other currently working code. Updates #54225. Change-Id: Ic379696079f4729b1dd6a66994a58cca50281a84 Reviewed-on: https://go-review.googlesource.com/c/go/+/429655 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@golang.org> 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-08-15cmd/compile: fix ICE when checking implicit dot for method callCuong Manh Le
CL 414836 limited the check for implicit dot for method call enabled by a type bound. However, the checking condition for ODOTMETH only is not right. For example, for promoted method, we have a OXDOT node instead, and we still have to check for implicit dot in this case. However, if the base type and embedded types have the same method name, e.g in issue #53419, typecheck.AddImplicitDots will be confused and result in an ambigus selector. To fix this, we ensure methods for the base type are computed, then only do the implicit dot check if we can find a matched method. Fixes #54348 Change-Id: Iefe84ff330830afe35c5daffd499824db108da23 Reviewed-on: https://go-review.googlesource.com/c/go/+/422274 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2022-08-11cmd/compile: fix wrong typeparams for selector expr with embedded generic typeCuong Manh Le
For selector expression "x.M" where "M" is a promoted method, irgen is using the type of receiver "x" for determining the typeparams for instantiation. However, because M is a promoted method, so its associated receiver is not "x", but "x.T" where "T" is the embedded field of "x". That casues a mismatch when converting non-shape types arguments. Fixing it by using the actual receiver which has the method, instead of using the base receiver. Fixes #53982 Change-Id: I1836fc422d734df14e9e6664d4bd014503960bfc Reviewed-on: https://go-review.googlesource.com/c/go/+/419294 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2022-08-01cmd/compile: fix wrong dict pass condition for type assertionsWayne Zuo
Fixes #54135 Change-Id: I2b27af8124014b2699ea44bdc765e1fb8f6c8028 Reviewed-on: https://go-review.googlesource.com/c/go/+/420394 Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-07-24cmd/compile/internal/noder: correct spelling errors for instantiationjacobishao
Change-Id: I8091b3181e6dd0c335763c411a6a64026fe5a651 GitHub-Last-Rev: 505c6caa9cd4538f76dde4287b9266e8947e395e GitHub-Pull-Request: golang/go#54024 Reviewed-on: https://go-review.googlesource.com/c/go/+/419315 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
2022-07-13cmd/compile: fix type assert in dict passWayne Zuo
For type assertions, if src type is empty interface, we should use normal type assertions rather than dynamic type assertions. Fixes #53762 Change-Id: I596b2e4ad647fe5e42ad884f7273c78f8f50dac2 Reviewed-on: https://go-review.googlesource.com/c/go/+/416736 Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-07-08cmd/compile: don't convert to interface{} for un-comparable types in generic ↵Cuong Manh Le
switch Fixes #53635 Change-Id: I41f383be8870432fc0d29fa83687911ddd8217f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/415634 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-07-06cmd/compile: only check implicit dots for method call enabled by a type boundCuong Manh Le
Fixes #53419 Change-Id: Ibad64f5c4af2112deeb0a9ecc9c589b17594bd05 Reviewed-on: https://go-review.googlesource.com/c/go/+/414836 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-06-28cmd/compile: fix generic inter-inter comparisons from value switch statementsCuong Manh Le
If value is a non-empty interface and has shape, we still need to convert it to an interface{} first. Fixes #53477 Change-Id: I516063ba4429a6cc24c483758387ec13815fc63e Reviewed-on: https://go-review.googlesource.com/c/go/+/414834 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-06-22cmd/compile: don't use dictionary convert to shaped empty interfaceWayne Zuo
Fixes: #53254 Change-Id: I3153d6ebb9f25957b09363f45c5cd4651ee84c2d Reviewed-on: https://go-review.googlesource.com/c/go/+/410655 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2022-06-22cmd/compile: fix assert condition in generic method callWayne Zuo
Fixes #53406. Change-Id: If7ae39ec1042a792d82a0a2de96d168c22d8ab71 Reviewed-on: https://go-review.googlesource.com/c/go/+/412614 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org> Auto-Submit: Alex Rakoczy <alex@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
2022-06-18cmd/compile: skip substituting closures in unsafe builtins argumentsCuong Manh Le
For unsafe.{Alignof,Offsetof,Sizeof}, subster will transform them them to OLITERAL nodes, and discard their arguments. However, any closure in their children nodes were already processed and added to declaration queue. Thus, we lack of information for generating instantiation for the closure. To fix it, just skip substituting the closures if we are going to edit the children nodes of unsafe builtins. Fixes #53390 Change-Id: Ia815cd05af9dc0491f10faac4399f378ac53dec6 Reviewed-on: https://go-review.googlesource.com/c/go/+/412794 Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-06-13cmd/compile: fix missing dict pass for type assertionsCuong Manh Le
For type assertions, if either src or dst type has shape, we must convert them to dynamic type assertions. Fixes #53309 Change-Id: Ia3362fa67c011febcbdb5b26f856d081b5c366de Reviewed-on: https://go-review.googlesource.com/c/go/+/411617 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2022-05-26cmd/compile: mark closures made for generic function expressions as wrappersKeith Randall
Fixes #52237 Change-Id: I7488020c8d157e069202017a293d18230e3aef0d Reviewed-on: https://go-review.googlesource.com/c/go/+/408876 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2022-05-16cmd/compile/internal/ir: more idiomatic DynamicType{,AssertExpr}Matthew Dempsky
Rename DynamicType's "X" field to "RType". Split DynamicTypeAssertExpr's "T" field into "RType" and "ITab", the same as DynamicType, updating all uses accordingly. Change-Id: I8cec8171349c93234a10ac50708f800dee6fb1d2 Reviewed-on: https://go-review.googlesource.com/c/go/+/405334 Auto-Submit: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
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-05-05cmd/compile: remove ir.TypeAssertExpr.NtypeMatthew Dempsky
As with ir.CompLitExpr.Ntype, there's no need for ir.TypeAssertExpr.Ntype in a pure-types2 world. Change-Id: Iff48c98330f072fd6b26099e13a19c56adecdc42 Reviewed-on: https://go-review.googlesource.com/c/go/+/403842 Reviewed-by: David Chase <drchase@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-05-03cmd/compile: use dictionary to convert type to shaped interface typeWayne Zuo
When we convert a type to a shaped interface type, we are not able to recognize the itab. So passing the itab by dictionary as the workaround. Fixes #52026. Change-Id: I75c23c7dd215daf9761dc24116a8af2c28c6d948 Reviewed-on: https://go-review.googlesource.com/c/go/+/401034 Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2022-05-02cmd/compile: simplify code from CL 398474Matthew Dempsky
This CL: 1. extracts typecheck.LookupNum into a method on *types.Pkg, so that it can be used with any package, not just types.LocalPkg, 2. adds a new helper function closureSym to generate symbols in the appropriate package as needed within stencil.go, and 3. updates the existing typecheck.LookupNum+Name.SetSym code to call closureSym instead. No functional change (so no need to backport to Go 1.18), but a little cleaner, and avoids polluting types.LocalPkg.Syms with symbols that we won't end up using. Updates #52117. Change-Id: Ifc8a3b76a37c830125e9d494530d1f5b2e3e3e2a Reviewed-on: https://go-review.googlesource.com/c/go/+/403197 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2022-04-28cmd/compile: set correct package for vars/params/results from nested ↵Cuong Manh Le
instantiation Fixes #52117 Change-Id: Ib5b2cdbdbce1d516aa10a0df349449b756f2f404 Reviewed-on: https://go-review.googlesource.com/c/go/+/398474 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-04-18cmd/compile: fix missing source information in ssa viewhopehook
Endlineno is lost when we call "genericSubst" to create the new instantiation of the generic function. This will cause "readFuncLines" to fail to read the target function. To fix this issue, as @mdempsky pointed out, add the line in cmd/compile/internal/noder/stencil.go: newf.Endlineno = gf.Endlineno Fixes #51988 Change-Id: Ib408e4ed0ceb68df8dedda4fb551309e8385aada Reviewed-on: https://go-review.googlesource.com/c/go/+/399057 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2022-03-26Revert "cmd/compile: stop interface conversions for generic method calls ↵Keith Randall
from allocating" This reverts commit e550c3054586a224d949cc8fa030bac0887bee51. Reason for revert: Method bound calls are no longer implemented using interface calls, so it is no longer necessary. Leaving the test, though. Change-Id: I80f1e4cd921063cd27ca8f07998316ca282e075b Reviewed-on: https://go-review.googlesource.com/c/go/+/395594 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-26cmd/compile: use method expression closures to implement bound method callsKeith Randall
When we have x.M(args) where x is a value of type parameter type, we currently cast x to the bound of that type parameter (which is an interface) and then invoke the method on that interface. That's pretty inefficient because: 1) We need to convert x to an interface, which often requires allocation. With CL 378178 it is at least stack allocation, but allocation nontheless. 2) We need to call through wrapper functions to unpack the interface into the right argument locations for the callee. Instead, let's just call the target directly. The previous CL to this one added method expression closures to the dictionary, which is a simple captureless closure that implements T.M for type parameter T and method M. So to implement x.M(args) for x of type T, we use methodexpr(T,M)(x, args). We just need to move x from the receiver slot to the first argument, and use the dictionary entry to implement the polymorphism. This works because we stencil by shape, so we know how to marshal x for the call even though we don't know its exact type. We should be able to revert CL 378178 after this one, as that optimization will no longer be necssary as we're not converting values to interfaces to implement this language construct anymore. Update #50182 Change-Id: I813de4510e41ab63626e58bd1167f9ae93016202 Reviewed-on: https://go-review.googlesource.com/c/go/+/385274 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-26cmd/compile: implement generic method expressions with closures in dictionaryKeith Randall
Currently we do quite a dance for method expressions on generic types. We write a new closure, and in that closure convert the receiver to an interface with the required method, then call the target using an interface call. Instead in this CL, we just allocate a (captureless) closure in the dictionary which implements that method expression. This CL makes method expressions faster and simpler. But the real win is some followon CLs, where we can use the same closure to implement bound method calls using the same closure, instead of converting to interface and having wrappers convert back. Much faster and simpler. Still thinking about how to do method values. The receiver still needs to be captured, so there must be some closure involved, I think. Update #50182 Change-Id: I1fbd57e7105663f8b049955b8f4111649a5f4aa8 Reviewed-on: https://go-review.googlesource.com/c/go/+/385254 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-21cmd/compile: replace Type.OrigSym with Type.OrigTypeMatthew Dempsky
First law of cmd/compile frontend development: thou shalt not rely on types.Sym. This CL replaces Type.OrigSym with Type.OrigType, which semantically matches what all of the uses within the frontend actually care about, and avoids using types.Sym, which invariably leads to mistakes because symbol scoping in the frontend doesn't work how anyone intuitively expects it to. Fixes #51765. Change-Id: I4affe6ee0718103ce5006ab68aa7e1bb0cac6881 Reviewed-on: https://go-review.googlesource.com/c/go/+/394274 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: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2022-03-14cmd/compile: fix wrong dict param when getting dict typeCuong Manh Le
CL 338129 added getDictionaryType to get the dictionary type from the specified dict param, but still using the one in info.dictParam, which is wrong. Fixes #51413 Change-Id: Ie13460c1e5751c4c5fc44479a44f6eed8b3b06e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/391994 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2022-03-10cmd/compile: fix expression switches using type parametersKeith Randall
Both the thing we're switching on, as well as the cases we're switching for. Convert anything containing a type parameter to interface{} before the comparison happens. Fixes #51522 Change-Id: I97ba9429ed332cb7d4240cb60f46d42226dcfa5f Reviewed-on: https://go-review.googlesource.com/c/go/+/391594 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-02-28cmd/compile: fix case for structural types where we should be looking at ↵Dan Scales
typeparams In getInstantiation, we were not computing tparams correctly for the case where the receiver of a method was a fully-instantiated type. This wasn't affecting later parts of the function, since method instantiations of fully-instantiated types were already being calculated in an earlier path. But it did give us a non-typeparam when trying to see if a shape was associated with a type param with a structural type. The fix is just to get the typeparams associated with the base generic type. Then we can eliminate a conditional check later in the code. The tparam parameter of Shapify should always be non-nil Fixes #51367 Change-Id: I6f95fe603886148b2dad0c581416c51373c85009 Reviewed-on: https://go-review.googlesource.com/c/go/+/388116 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2022-02-26cmd/compile: ensure dictionary assignment statements are defining statementsKeith Randall
The problem in 51355 is that escape analysis decided that the dictionary variable was captured by reference instead of by value. We want dictionaries to always be captured by value. Escape analysis was confused because it saw what it thought was a reassignment of the dictionary variable. In fact, it was the only assignment, it just wasn't marked as the defining assignment. Fix that. Add an assert to make sure this stays true. Fixes #51355 Change-Id: Ifd9342455fa107b113f5ff521a94cdbf1b8a7733 Reviewed-on: https://go-review.googlesource.com/c/go/+/388115 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Dan Scales <danscales@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
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-01-24cmd/compile: distinguish bound calls/field access in getInstInfoDan Scales
Given we have support for field access to type params with a single structural type, we need to distinguish between methods calls and field access when we have an OXDOT node on an expression which is a typeparam (or correspondingly a shape). We were missing checks in getInstInfo, which figures out the dictionary format, which then caused problems when we generate the dictionaries. We don't need/want dictionary entries for field access, only for bound method calls. Added a new function isBoundMethod() to distinguish OXDOT nodes which are bound calls vs. field accesses on a shape. Removed isShapeDeref() - we can't have field access or method call on a pointer to variable of type param type. Fixes #50690 Change-Id: Id692f65e6f427f28cd2cfe474dd30e53c71877a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/379674 Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2022-01-18cmd/compile: support field access for typeparam with structural constraintDan Scales
In the compiler, we need to distinguish field and method access on a type param. For field access, we avoid the dictionary access (to create an interface bound) and just do the normal transformDot() (which will create the field access on the shape type). This field access works fine for non-pointer types, since the shape type preserves the underlying type of all types in the shape. But we generally merge all pointer types into a single shape, which means the field will not be accessible via the shape type. So, we need to change Shapify() so that a type which is a pointer type is mapped to its underlying type, rather than being merged with other pointers. Because we don't want to change the export format at this point in the release, we need to compute StructuralType() directly in types1, rather than relying on types2. That implementation is in types/type.go, along with the helper specificTypes(). I enabled the compiler-related tests in issue50417.go, added an extra test for unnamed pointer types, and added a bunch more tests for interesting cases involving StructuralType(). I added a test issue50417b.go similar to the original example, but also tests access to an embedded field. I also added a unit test in cmd/compile/internal/types/structuraltype_test.go that tests a bunch of unusual cases directly (some of which have no structural type). Updates #50417 Change-Id: I77c55cbad98a2b95efbd4a02a026c07dfbb46caa Reviewed-on: https://go-review.googlesource.com/c/go/+/376194 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-01-13cmd/compile: stop interface conversions for generic method calls from allocatingKeith Randall
Let T be a type parameter, and say we instantiate it with S, a type that isn't pointer-like (e.g. a pair of ints, or as in 50182, a slice). Then to call a method m on a variable of type T, the compiler does essentially: var v T = ... i := (interface{m()})(v) i.m() The conversion at that second line allocates, as we need to make the data word for an interface. And in the general case, that interface may live an arbitrarily long time. But in this case, we know it doesn't. The data word of i has type *S. When we call i.m, we can't call S.m directly. It is expecting an S, not a *S. We call through a wrapper defined on *S, which looks like: func (p *S) m() { var s S = *p s.m() } The value passed in for p is exactly the data word mentioned above. It never escapes anywhere - the wrapper copies a type S variable out of *p and p is dead after that. That means that in the situation where we build an interface for the explicit purpose of calling a method on it, and use that built interface nowhere else, the allocation of the data word for that interface is known to die before the call returns and thus can be stack allocated. One tricky case is that although the allocation of the backing store of the interface conversion doesn't escape, pointers we store *inside* that allocation might escape (in fact they definitely will, unless we can devirtualize the receiver). Fixes #50182 Change-Id: I40e893955c2e6871c54ccecf1b9f0cae17871b0d Reviewed-on: https://go-review.googlesource.com/c/go/+/378178 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-01-10cmd/compile: fix interaction between generics and inliningDan Scales
Finally figured out how to deal with the interaction between generics and inlining. The problem has been: what to do if you inline a function that uses a new instantiated type that hasn't been seen in the current package? This might mean that you need to do another round of function/method instantiatiations after inlining, which might lead to more inlining, etc. (which is what we currently do, but it's not clear when you can stop the inlining/instantiation loop). We had thought that one solution was to export instantiated types (even if not marked as exportable) if they are referenced in exported inlineable functions. But that was quite complex and required changing the export format. But I realized that we really only need to make sure the relevant dictionaries and shape instantiations for the instantiated types are exported, not the instantiated type itself and its wrappers. The instantiated type is naturally created as needed, and the wrappers are generated automatically while writing out run-time type (making use of the exported dictionaries and shape instantiations). So, we just have to make sure that those dictionaries and shape instantiations are exported, and then they will be available without any extra round of instantiations after inlining. We now do this in crawler.go. This is especially needed when the instantiated type is only put in an interface, so relevant dictionaries/shape instantiations are not directly referenced and therefore exported, but are still needed for the itab. This fix avoids the phase ordering problem where we might have to keep creating new type instantiations and instantiated methods after each round of inlining we do. Removed the extra round of instantiation/inlining that were added in the previous fix. The existing tests test/typeparam{geninline.go,structinit.go} already test this situation of inlining a function referencing a new instantiated type. Added the original example from issue 50121 as test (has 5 packages), since it found a problem with this code that the current simpler test for 50121 did not find. Change-Id: Iac5d0dddf4be19376f6de36ee20a83f0d8f213b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/375494 Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2022-01-04cmd/compile: save selector/inst info for generic method/function callsDan Scales
In the dict info, we need to save the SelectorExpr of a generic method call when making its sub-dictionary entry. The generic method call will eventually be transformed into a function call on the method shape instantiation, so we may not always have the selector info available when we need it to create a dictionary. We use this SelectorExpr as needed if the relevant call node has already been transformed. Similarly, we save the InstExpr of generic function calls, since the InstExpr will be dropped when the function call is transformed to a call to a shape instantiation. We use this InstExpr if the relevant function call has already been transformed. Added an extra generic function Some2 and a call to it from Some that exercises the generic function case. The existing test already tests the method call case. Fixes #50264 Change-Id: I2c7c7d79a8e33ca36a5e88e64e913c57500c97f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/373754 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>
2021-12-13cmd/compile: avoid re-instantiating method that is already importedDan Scales
We can import an shape-instantiated function/method for inlining purposes. If we are instantiating the methods of a instantiated type that we have seen, and it happens to need a shape instantiation that we have imported, then don't re-create the instantiation, since we will end up with conflicting/duplicate definitions for the instantiation symbol. Instead, we can just use the existing imported instantation, and enter it in the instInfoMap[]. Fixes #50121 Change-Id: I6eeb8786faad71106e261e113048b579afad04fa Reviewed-on: https://go-review.googlesource.com/c/go/+/371414 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2021-11-19cmd/compile: don't run ComputeAddrTaken on imported generic functionsDan Scales
It causes a crash because of the unexpected XDOT operation. It's not needed, since we will run ComputeAddrTaken() on function instantiations after stenciling. And it's not always correct, since we may not be able to distinguish between a array and a slice, if a type is dependent on a type param. However, we do need to call ComputeAddrTaken on instantiations created during inlining, since that is after the main ComputeAddrTaken pass. Fixes #49659 Change-Id: I0bb610cf11f14e4aa9068f6ca2a012337b069c79 Reviewed-on: https://go-review.googlesource.com/c/go/+/365214 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-11-15cmd/compile: fix position info for implicit nodes due to genericsDan Scales
The main fix is that we should call ir.SetPos() at the beginning of (*subster).node.edit function, since that is analogous to the ir.SetPos() at the beginning of typecheck.typecheck(). It ensures that transform functions can use base.Pos() with appropriate results, just like their corresponding tc*() functions do. A small fix is to make sure that the new nodes creates for dictionary references have the correct position based on the location of the function call. Another small fix is to the use of base.Pos when creating a new selector expression (including implicit XDOTs) for a method expression in buildClosure(). Also, I converted the final use of base.Pos in stencil.go to src.NoXPos, since the nodes created by AddImplicitDots will be checked for their type, but won't actually be used. I also needed to add an ir.SetPos() at the beginning of transformCall(), since transformCall() is called in the modify and dict passes, when we base.Pos is not being set for each node. This change fixes all the line numbering problems printed out from Alessandro's program, except for auto-generated functions (which I think are fine). Fixes #49523 Change-Id: I9836a497b7beba25ecafdde653a6c2036a3020d3 Reviewed-on: https://go-review.googlesource.com/c/go/+/363835 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-11-12cmd/compile: fix missing transformEarlyCall for OXDOT in subster.nodeCuong Manh Le
Like OFUNCINST, in case of OXDOT call expression, the arguments need to be transformed earlier, so any needed CONVIFACE nodes are exposed. Fixes #49538 Change-Id: I275ddf6f53a9cadc8708e805941cdf7bdffabba9 Reviewed-on: https://go-review.googlesource.com/c/go/+/363554 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-11-11cmd/compile: ensure stenciled function bodies are nonemptyKeith Randall
Our compiler gets confused between functions that were declared with no body, and those which have a body but it is empty. Ensure that when stenciling, we generate a nonempty body. The particular test that causes this problem is in cmd/compile/internal/gc/main.go:enqueueFunc. It thinks that if a function has no body, then we need to generate ABI wrappers for it, but not compile it. Fixes #49524 Change-Id: Id962666a2098f60a2421484b6a776eafdc4f4a63 Reviewed-on: https://go-review.googlesource.com/c/go/+/363395 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-11-11cmd/compile: fix missing ddd when building call for function instantiation ↵Cuong Manh Le
closure When building a call expression for function instantiation closure, if it's a variadic function, the CallExpr.IsDDD must be set for typecheck to work properly. Otherwise, there will be a mismatch between the arguments type and the function signature. Fixes #49516 Change-Id: I0af90ee3fcc3e6c8bba8b20e331e044cbce17985 Reviewed-on: https://go-review.googlesource.com/c/go/+/363314 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: Keith Randall <khr@golang.org>
2021-11-09cmd/compile: disable doubleCheck and remove unused checkDictionaryDan Scales
In stencil.go, change doubleCheck to false, which will turn off some double-checking code which isn't needed generally, now that we have lots of tests of end-to-end runs. Also, removed checkDictionary() which is unused and is unlikely to be useful in the future. Change-Id: I4e5acceab80f4904b174422bae21ca82cf04f943 Reviewed-on: https://go-review.googlesource.com/c/go/+/361923 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-11-09cmd/compile: fix irgen mis-handling of ... argument when creating closureCuong Manh Le
When bulding formal arguments of newly created closure, irgen forgets to set "..." field attribute, causing type mismatched between the closure function and the ONAME node represents that closure function. Fixes #49432 Change-Id: Ieddaa64980cdd3d8cea236a5a9de0204ee21ee39 Reviewed-on: https://go-review.googlesource.com/c/go/+/361961 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-11-02cmd/compile: fix panic when refer to method of imported instantiated typeCuong Manh Le
In case of reference to method call of an imported fully-instantiated type, nameNode.Func will be nil causes checkFetchBody panic. To fix this, make sure checkFetchBody is only called when Func is not nil. Fixes #49246 Change-Id: I32e9208385a86d4600d8ebf6f5efd8fca571ea16 Reviewed-on: https://go-review.googlesource.com/c/go/+/360056 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-10-26cmd/compile: clean up the switch statements in (*genInst).node()Dan Scales
There were two main outer switch statements in node() that can just be combined. Also, for simplicity, changed an IsCmp() conditional into just another case in the switch statement. Also, the inner OCALL switch statement had a bunch of fairly duplicate cases. Combined the cases that all had no special semantics, into a single default case calling transformCall(). In the OCALL case in dictPass(), got rid of a check for OFUNCINST (which will always have been removed by this point). Also, eliminated an assert that could cause unneded failures. transformCall() should always be called if the node op is still OCALL, so no need to assert on the ops of call.X. Added an extra test in issue47078.go, to explicitly check for case where the X argument of a call is a DOTTYPE. Change-Id: Ifb3f812ce12820a4ce08afe2887f00f7fc00cd2f Reviewed-on: https://go-review.googlesource.com/c/go/+/358596 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-10-25cmd/compile: revert most of CL 349169Keith Randall
The method of using references to dictionaries to hold methods live during linker deadcode elimination wasn't working very well. I implemented a new scheme in the CL below this, so this CL strips out the old method. The new method has the added benefit of having 0 runtime overhead (unlike the stuff we're ripping out here, which does have a small overhead). Update #48047 Change-Id: I68ac57119792d53c58f1480f407de6ab2bb53211 Reviewed-on: https://go-review.googlesource.com/c/go/+/357836 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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 23:59:23 +0000