aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/helpers.go
AgeCommit message (Collapse)Author
2024-07-23runtime,internal: move runtime/internal/sys to internal/runtime/sysDavid Chase
Cleanup and friction reduction For #65355. Change-Id: Ia14c9dc584a529a35b97801dd3e95b9acc99a511 Reviewed-on: https://go-review.googlesource.com/c/go/+/600436 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-01-17cmd/compile: call types2.Unalias to be ready for GODEBUG=gotypesalias=1Robert Griesemer
types2.Unalias is not needed if we know we have a core or underlying type. Also, types of declared functions (signatures) cannot be aliases (this includes tuples). Fixes #65125. Change-Id: I1faa26b66f6c646719e830dd661136fae86f3775 Reviewed-on: https://go-review.googlesource.com/c/go/+/556036 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-12-01cmd/compile: fix typecheck range over rune literalCuong Manh Le
With range over int, the rune literal in range expression will be left as untyped rune, but idealType is not handling this case, causing ICE. Fixing this by setting the concrete type for untyped rune expresison. Fixes #64471 Change-Id: I07a151c54ea1d9e1b92e4d96cdfb6e73dca13862 Reviewed-on: https://go-review.googlesource.com/c/go/+/546296 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-10-09cmd/compile: fix typecheck range over negative integerCuong Manh Le
Before range over integer, types2 leaves constant expression in RHS of non-constant shift untyped, so idealType do the validation to ensure that constant value must be an int >= 0. With range over int, the range expression can also be left untyped, and can be an negative integer, causing the validation false. Fixing this by relaxing the validation in idealType, and moving the check to Unified IR reader. Fixes #63378 Change-Id: I43042536c09afd98d52c5981adff5dbc5e7d882a Reviewed-on: https://go-review.googlesource.com/c/go/+/532835 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2023-09-12cmd/compile/internal/ir: add NewZeroMatthew Dempsky
This constructs a zero value of any type, which helps address some corner case scenarios. It should also eventually handle the predeclared "zero" value, at least as currently implemented in go.dev/cl/520336. For #61372. Change-Id: I3a86a94fd8fa388c9c6bf281da8aa532b3da00fc Reviewed-on: https://go-review.googlesource.com/c/go/+/527696 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-09-11cmd/compile/internal/ir: add Type param to NewBasicLitMatthew Dempsky
This CL adds an explicit Type parameter to NewBasicLit so that callers can directly construct typed OLITERAL nodes. Change-Id: I0ab50ac3d7ddb7adcc903633a62ac496921165e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/527096 Auto-Submit: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-09-08cmd/compile/internal/noder: stop preserving original const stringsMatthew Dempsky
One of the more tedious quirks of the original frontend (i.e., typecheck) to preserve was that it preserved the original representation of constants into the backend. To fit into the unified IR model, I ended up implementing a fairly heavyweight workaround: simply record the original constant's string expression in the export data, so that diagnostics could still report it back, and match the old test expectations. But now that there's just a single frontend to support, it's easy enough to just update the test expectations and drop this support for "raw" constant expressions. Change-Id: I1d859c5109d679879d937a2b213e777fbddf4f2f Reviewed-on: https://go-review.googlesource.com/c/go/+/526376 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-08-25cmd/compile/internal/noder: avoid ir.Node temps in FixValueMatthew Dempsky
Instead of constructing an untyped basic literal IR node, having typecheck convert it and return a new one, only to extract the constant.Value; just have typecheck export the underlying value conversion function, so we can call it directly. Change-Id: Ie98f5362b3926a728d80262b0274a0b4fd023eaf Reviewed-on: https://go-review.googlesource.com/c/go/+/522878 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-08-20cmd/compile/internal/typecheck: add selector helpersMatthew Dempsky
This CL refactors common patterns for constructing field and method selector expressions. Notably, XDotField and XDotMethod are now the only two functions where a SelecterExpr with OXDOT is constructed. Change-Id: I4c087225d8b295c4a6a92281ffcbcabafe2dc94d Reviewed-on: https://go-review.googlesource.com/c/go/+/520979 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-18cmd/compile: construct more IR nodes as typedMatthew Dempsky
As of this CL, all OLITERAL, OLINKSYMOFFSET, ONIL, and OTYPE nodes are constructed as typed and typechecked. Change-Id: I39b2ad772a9b0419c701890a505a0949f9ea456e Reviewed-on: https://go-review.googlesource.com/c/go/+/520795 Reviewed-by: Dmitri Shuralyov <dmitshur@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: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-07-21cmd/compile/internal/noder: remove un-used funcs/varsCuong Manh Le
Change-Id: I755406e6c5b6a8cdaeeed8cd12d756e3847c8d4f Reviewed-on: https://go-review.googlesource.com/c/go/+/506475 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-01-26cmd/compile/internal/types: remove TTYPEPARAM and TUNION typesMatthew Dempsky
These were used by the nounified frontend for representing uninstantiated generic types; however, the unified frontend only needs types1 to represent instantiated types. Updates #57410. Change-Id: Iac417fbf2b86f4e08bd7fdd26ae8ed17395ce833 Reviewed-on: https://go-review.googlesource.com/c/go/+/458621 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-29cmd/compile: keep typecheck results in syntax treeKeith Randall
Saves on both space and cost of map operations. Saves about 3% in compile time. name old time/op new time/op delta Template 251ms ± 2% 244ms ± 1% -2.78% (p=0.000 n=8+8) Unicode 149ms ± 5% 135ms ± 2% -9.03% (p=0.000 n=10+10) GoTypes 1.38s ± 1% 1.35s ± 1% -2.29% (p=0.000 n=10+10) Compiler 115ms ± 2% 112ms ± 2% -2.50% (p=0.001 n=10+9) SSA 11.9s ± 0% 11.4s ± 0% -4.04% (p=0.000 n=9+10) Flate 153ms ± 1% 148ms ± 1% -3.32% (p=0.000 n=10+9) GoParser 284ms ± 2% 280ms ± 1% -1.70% (p=0.002 n=10+10) Tar 209ms ± 2% 205ms ± 2% -1.98% (p=0.004 n=9+10) XML 287ms ± 2% 281ms ± 1% -2.06% (p=0.000 n=10+10) LinkCompiler 508ms ± 2% 501ms ± 2% -1.31% (p=0.024 n=9+9) ExternalLinkCompiler 2.66s ± 3% 2.63s ± 4% ~ (p=0.280 n=10+10) LinkWithoutDebugCompiler 338ms ± 3% 330ms ± 3% -2.21% (p=0.009 n=10+10) StdCmd 21.5s ± 1% 20.8s ± 1% -3.27% (p=0.000 n=9+9) [Geo mean] 615ms 597ms -2.91% name old user-time/op new user-time/op delta Template 344ms ± 2% 324ms ± 3% -6.01% (p=0.000 n=9+9) Unicode 215ms ±11% 192ms ± 2% -10.84% (p=0.000 n=10+9) GoTypes 1.99s ± 2% 1.93s ± 2% -2.73% (p=0.000 n=10+10) Compiler 142ms ± 4% 140ms ± 3% -1.89% (p=0.031 n=9+9) SSA 17.4s ± 1% 17.0s ± 5% ~ (p=0.113 n=9+10) Flate 200ms ± 4% 196ms ± 6% ~ (p=0.190 n=10+10) GoParser 388ms ± 3% 378ms ± 4% -2.59% (p=0.004 n=9+10) Tar 278ms ± 8% 277ms ± 2% ~ (p=0.315 n=10+10) XML 387ms ± 2% 381ms ± 2% -1.63% (p=0.005 n=8+8) LinkCompiler 784ms ± 4% 778ms ± 2% ~ (p=0.436 n=10+10) ExternalLinkCompiler 2.45s ± 1% 2.42s ± 1% -1.11% (p=0.001 n=10+9) LinkWithoutDebugCompiler 374ms ± 3% 366ms ± 2% -2.15% (p=0.010 n=10+9) [Geo mean] 600ms 583ms -2.91% Change-Id: I9552a70d6a2ad500e9acd8815762b761be3c2ff9 Reviewed-on: https://go-review.googlesource.com/c/go/+/432897 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2022-08-31cmd/compile: reject not-in-heap types as type argumentsMatthew Dempsky
After running the types2 type checker, walk info.Instances to reject any not-in-heap type arguments. This is feasible to check using the types2 API now, thanks to #46731. Fixes #54765. Change-Id: Idd2acc124d102d5a76f128f13c21a6e593b6790b Reviewed-on: https://go-review.googlesource.com/c/go/+/427235 Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com>
2022-08-08cmd/compile: treat constants to type parameter conversion as non-constant in ↵Cuong Manh Le
Unified IR Fixes #54307 Change-Id: Idcbdb3b1cf7c7fd147cc079659f29a9b5d17e6e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/421874 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@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-06-09[dev.unified] test: relax issue7921.go diagnostic messageCuong Manh Le
For constants literal, iimport/iexport read/write them as basic literal nodes. So they are printed in diagnostic message as Go syntax. So "foo" will be reported as string("foo"). Unified IR read/write the raw expression as string value, and when printed in diagnostic, the string value is written out exactly as-is, so "foo" will be written as "foo". Thus, this CL relax the test in issue7921.go to match the string value only. Updates #53058 Change-Id: I6fcf4fdcfc4b3be91cb53b081c48bd57186d8f35 Reviewed-on: https://go-review.googlesource.com/c/go/+/410795 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@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>
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>
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-27cmd/compile: keep methods on generic types from being deadcode eliminatedKeith Randall
We currently make dictionaries contain a relocation pointing to methods that generic code might use, so that those methods are not deadcode eliminated. However, with inlining we can end up not using the dictionary, making the reference from the dictionary to the method no longer keep the method alive. Fix this by keeping the dictionary alive at generic interface call sites. It's a bit of overkill, as we only need to keep the dictionary statically alive. We don't actually need it dynamically alive, which is what KeepAlive does. But it works. It ends up generating a LEAQ + stack spill that aren't necessary, but that's pretty low overhead. To make this work, I needed to stop generating methods on shape types. We should do this anyway, as we shouldn't ever need them. But currently we do use them! issue44688.go has a test that only works because it calls a method on a shape type. I've disabled that test for now, will work on it in a subsequent CL. Fixes #48047 Change-Id: I78968868d6486c1745f51b8b43be0898931432a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/349169 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> Reviewed-by: Than McIntosh <thanm@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-20cmd/compile: delay all transforms for generic funcs/methodsDan Scales
This change cleans up the code, by just delaying all transforms on generic function methods/functions until stenciling time. That way, we don't have extra code to decide whether to delay, or an extra value for the typecheck flag. We are already doing all possible transforms at stencil time anyway, so no changes to the stenciling code. transform.go includes a change for one case where we check for shape rather than tparam, now that we only apply transforms to stenciled functions, not generic functions. This change is to allow CONVIFACE node to be correctly inserted (needed for dictionaries), even with this strange code that doesn't add the CONVIFACE node if the concrete type is NOT huge... Change-Id: I5f1e71fab11b53385902074915b3ad85f8e753fa Reviewed-on: https://go-review.googlesource.com/c/go/+/350736 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-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-08-23cmd/compile: fixes for non-constant Sizeof/Alignof/OffsetofDan Scales
Includes Robert's suggested fix in validate.go to not fail on non-constant alignof/offsetof/sizeof calls. Further changes to wait on transforming these calls until stenciling time, when we can call EvalConst() to evaluate them once all the relevant types are known. Added a bunch of new tests for non-constant Sizeof/Alignof/Offsetof. Fixes #47716 Change-Id: I469af888eb9ce3a853124d919eda753971009b3e Reviewed-on: https://go-review.googlesource.com/c/go/+/344250 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-09[dev.typeparams] cmd/compile: call transformArgs before early typecheckaste ↵Dan Scales
in noder In the cases where we do an early call to typecheckaste() in noder to expose CONVIFACE nodes, we need a preceding call to transformArgs(). This is needed to allow typecheckaste() to run correctly, in the case of f(g()), where g has multiple return values. I also cleaned up the code a bit and commented the code in Call(), and we do the call to typecheckaste() in several more cases. In stencil.go:stencil(), I moved the transformCall earlier for the OCALLMETH/ODOTMETH case, just as I did in my previous CL for OCALL/OFUNCINST. By doing this, transformArgs no longer needs to deal with the extra dictionary args. Therefore, I was able to simply transformArgs() to look like typecheckargs() again, and make use of RewriteMultiValue directly. Updates #47514 Change-Id: I49eb82ac05707e50c2e2fb03e39458a70491d406 Reviewed-on: https://go-review.googlesource.com/c/go/+/340531 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-23[dev.typeparams] Add CONVIFACE nodes in noder2, where possibleDan Scales
Changes to add CONVIFACE nodes where possible in noder2, even when the args are typeparams. The transformation to insert a CONVIFACE node can usually happen when there an obvious assignment/conversion to an interface type from a non-interface type. So, we now do this tranformation for: - direct conversions to an interface type - function arguments that are implicitly converted to an interface based on the parameter types. - EQ/NE comparison of an interface and a non-interface With this change, we can remove some special case checks for CONVIFACE nodes after transformation in node(), and instead just have the one check in the CONVIFACE check. Change-Id: I7cf2ef920aebf9e5553210aeaf19f344e128ca62 Reviewed-on: https://go-review.googlesource.com/c/go/+/336992 Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-07-21[dev.typeparams] cmd/compile: handle ++/-- in noder2 for operands with ↵Dan Scales
generic type types2 will have already proved the expression's type is compatible, so just assign the one const to have the same type as the operand. Fixes #47258. Change-Id: If0844e6bf6d0a5e6b11453b87df71353863ccc5d Reviewed-on: https://go-review.googlesource.com/c/go/+/336009 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-21[dev.typeparams] cmd/compile: added a builtins.go test, fixed one bugDan Scales
The builtins.go test is derived from cmd/compile/internal/types2/testdata/check/builtins.go2, after removing the error cases. Added a few extra tests for len/cap/append. Fixed one bug, which is that DELETE operations can't be transformed if their argument is a typeparam. Also, the tranform of LEN/CAP calls does not need to be delayed. Removed out-date references to the old typechecker in the comments. Change-Id: If7a21506a7ff63ff7c8e87ccd614ef4ff3a0d3c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/336010 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-04[dev.typeparams] cmd/compile: set Func.ClosureCalled in escape analysisMatthew Dempsky
The Func.ClosureCalled flag is an optimization used by escape analysis to detect closures that were directly called, so we know we have visibility of the result flows. It's not needed by any other phases of the compiler, so we might as well calculate it within escape analysis too. This saves some trouble during IR construction and trying to maintain the ClosureCalled flag through inlining and copying. Passes toolstash -cmp. Change-Id: Ic53cecb7ac439745c0dfba2cd202b9cc40f1e47c Reviewed-on: https://go-review.googlesource.com/c/go/+/332691 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>
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-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-04-05cmd/compile: get rid of Fields in types.Interface, use allMethods in ↵Dan Scales
types.Type instead Confusingly, the set of all methods of an interface is currently set in Fields field of types.Interface. This is true, even though there is already an allMethods field (and AllMethods method) of types.Type. Change so the set of all methods of an interface are stored in Type.allMethods, and Interface.Fields is removed. Update the comments for Methods and AllMethods. Change-Id: Ibc32bafae86831cba62606b079a855690612c759 Reviewed-on: https://go-review.googlesource.com/c/go/+/307209 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-03-31cmd/compile: deal with call.Use correctly for noder2, allow inlining of ↵Dan Scales
stenciled functions The setting of n.Use for a call node in transformCall() (and previously in Call()), was not corrrect, since it was trying to use the number of results of the call, rather than whether the call result was actually used. We are already setting n.Use to ir.CallUseStmt if the call node is directly a statement, so we just need to initialize n.Use to ir.CallExprStmt in Call(), which will get changed to ir.CallUseStmt at the statement level if it's used as a statement. Enable inlining of stenciled functions (just disabled for testing, easier debugging). The above n.Use fix was required for the inlining to work for two cases. Change-Id: Ie4ef6cd53fd4b20a4f3be31e629280909a545b7d Reviewed-on: https://go-review.googlesource.com/c/go/+/305913 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-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-25cmd/compile: add transform functions for OXDOT and builtinsDan Scales
Pull out the tranformation part of the typechecking functions for: - selector expressions (OXDOT) - calls to builtin functions (which go through the typechecker loop twice, once for the call and once for each different kind of builtin). Some of the transformation functions create new nodes that should have the same type as the original node. For consistency, now each of the transformation functions requires that the node passed in has its type and typecheck flag set. If the transformation function replaces or adds new nodes, it will set the type and typecheck flag for those new nodes. As usual, passes all the gotests, even with -G=3 enabled. Change-Id: Ic48b0ce5f58425f4a358afa78315bfc7c28066c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/304729 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-25cmd/compile: create/use noder2 transform functions for more node typesDan Scales
Pull out the transformation part of the typechecking functions for: - assignment statements - return statements - send statements - select statements - type conversions - normal function/method calls - index operations The transform functions are like the original typechecking functions, but with all code removed related to: - Detecting compile-time errors (already done by types2) - Setting the actual type of existing nodes (already done based on info from types2) - Dealing with untyped constants Moved all the transformation functions to a separate file, transform.go. Continuing with the same pattern, we delay transforming a node if it has any type params in its args, marking it with a typecheck flag of 3, and do the actual transformation during stenciling. Assignment statements are tricky, since their transformation must be delayed if any of the left or right-hands-sides are delayed. Still to do are: - selector expressions (OXDOT) - composite literal expressions (OCOMPLIT) - builtin function calls Change-Id: Ie608cadbbc69b40db0067a5536cf707dd974aacc Reviewed-on: https://go-review.googlesource.com/c/go/+/304049 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-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-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>
2021-03-15cmd/compile: add support for generic channels and type conversion during callsDan Scales
Add support for channels in subster.typ(). Add new test file chans.go. To support assignability of bidirectional channel args to directional channel params, I needed to type check generic calls after they are instantiated. (Eventually, we will create separate functions to just do the assignability logic, so we don't need to call the old typechecker in this case.) So, for generic calls, we now leave the call as OCALL (as a signal that the call still needs typechecking), and do typecheck.Call() during stenciling. Smaller changes: - Set the type of an instantiated OCLOSURE node (and not just the associated OFUNC node) - In instTypeName2, filter out the space that types2.TypeString inserts after a common in a typelist. Our standard naming requires no space after the comma. - With the assignability fix above, I no longer need the explicit conversions in cons.go. Change-Id: I148858bfc6708c0aa3f50bad7debce2b8c8c091f Reviewed-on: https://go-review.googlesource.com/c/go/+/301669 Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12cmd/compile: fix noder.Addr() to not call typecheckerDan Scales
Simple change to avoid calling the old typechecker in noder.Addr(). This fixes cases where generic code calls a pointer method with a non-pointer receiver. Added test typeparam/lockable.go that now works with this change. For lockable.go to work, also fix incorrect check to decide whether to translate an OXDOT now or later. We should delay translating an OXDOT until instantiation (because we don't know how embedding, etc. will work) if the receiver has any typeparam, not just if the receiver type is a simple typeparam. We also have to handle OXDOT for now in IsAddressable(), until we can remove calls to the old typechecker in (*irgen).funcBody(). Change-Id: I77ee5efcef9a8f6c7133564106a32437e36ba4bb Reviewed-on: https://go-review.googlesource.com/c/go/+/300990 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-02-10[dev.typeparams] cmd/compile: make type conversions by type parameters workDan Scales
When doing a type conversion using a type param, delay the transformation to OCONV/OCONVNOP until stenciling, since the nodes created depend on the actual type. Re-enable the fact.go test. Change-Id: I3d5861aab3dd0e781d767f67435afaf951dfe451 Reviewed-on: https://go-review.googlesource.com/c/go/+/290752 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-02-10[dev.typeparams] cmd/compile: handle calling a method on a type param in ↵Dan Scales
stenciling - Have to delay the extra transformation on methods invoked on a type param, since the actual transformation (including path through embedded fields) will depend on the instantiated type. I am currently doing the transformation during the stencil substitution phase. We probably should have a separate pass after noder2 and stenciling, which drives the extra transformations that were in the old typechecker. - We handle method values (that are not called) and method calls. We don't currently handle method expressions. - Handle type substitution in function types, which is needed for function args in generic functions. - Added stringer.go and map.go tests, testing the above changes (including constraints with embedded interfaces). Change-Id: I3831a937d2b8814150f75bebf9f23ab10b93fa00 Reviewed-on: https://go-review.googlesource.com/c/go/+/290550 TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-02-03[dev.typeparams] cmd/compile: deal with inferred type argumentsDan Scales
Create an extra OFUNCINST node as needed, if there are inferred type arguments for a generic function call. Change-Id: Id990c5bcbce2893377072a7e41c7c6785d1eab60 Reviewed-on: https://go-review.googlesource.com/c/go/+/288952 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-02-03[dev.typeparams] cmd/compile: add OFUNCINST/OTYPEINST nodes for generic ↵Dan Scales
func/type instantiation Expresses things more clearly, especially in cases like 'f := min[int]' where we create a xsgeneric function instantiation, but don't immediately call it. min[int](2, 3) now looks like: . CALLFUNC tc(1) Use:1 int # min1.go:11 int . . FUNCINST tc(1) FUNC-func(int, int) int # min1.go:11 FUNC-func(int, int) int . . . NAME-main.min tc(1) Class:PFUNC Offset:0 Used FUNC-func[T](T, T) T # min1.go:3 . . FUNCINST-Targs . . . TYPE .int Offset:0 type int . CALLFUNC-Args . . LITERAL-2 tc(1) int # min1.go:11 . . LITERAL-3 tc(1) int # min1.go:11 Remove the targs parameter from ir.NewCallExpr(), not needed anymore, since type arguments are included in the FUNCINST. Change-Id: I23438b75288330475294d7ace239ba64acfa641e Reviewed-on: https://go-review.googlesource.com/c/go/+/288951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-02-02[dev.typeparams] Handling multiple type arguments for call via new node OLISTDan Scales
Will now run "go tool compile -G=2 -W=2" on a simple generic function with multiple type parameters and a call to that function with multiple explicit type arguments. We will likely move to have a separate function/type instantiation node, in order distinguish these cases from normal index expressions. Change-Id: I0a571902d63785cc06240ed4ba0495923403b511 Reviewed-on: https://go-review.googlesource.com/c/go/+/288433 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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 19:54:02 +0000