aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/reader.go
AgeCommit message (Collapse)Author
2022-05-25internal/pkgbits: add Index typeMatthew Dempsky
Element indices are very common in the pkgbits API, so introduce a new defined type to help make that clearer. Change-Id: I8f9493e2335601c740eb403d1fdcd11183122907 Reviewed-on: https://go-review.googlesource.com/c/go/+/407435 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
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-13cmd/compile/internal/noder: remove unified IR assumptions on LocalPkg.Path == ""Matthew Dempsky
Replace `pkg.Path == ""` check with `pkg == types.LocalPkg`. This is a prep refactoring for CL 393715, which will properly initialize types.LocalPkg. Updates #51734. Change-Id: I7a5428ef1f422de396762b6bc6d323992834b27c Reviewed-on: https://go-review.googlesource.com/c/go/+/406056 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
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-05cmd/compile: change ir.NewCompLitExpr from Ntype to *types.TypeMatthew Dempsky
All callers were already using TypeNode to get an Ntype anyway, so just push the TypeNode constructor down into NewCompLitExpr. Prep refactoring for next CL to remove the Ntype field. Change-Id: I671935afca707aaab11d1c46e39902bd37a485ba Reviewed-on: https://go-review.googlesource.com/c/go/+/403840 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-05-05cmd/compile: remove ir.Name.NtypeMatthew Dempsky
No longer needed now that IR construction uses types2. Change-Id: If8b7aff80cd8472be7d87fd3a36da911a5df163c Reviewed-on: https://go-review.googlesource.com/c/go/+/403839 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-05-04cmd/compile: enable Asan check for global variablesfanzha02
With this patch, -asan option can detect the error memory access to global variables. So this patch makes a few changes: 1. Add the asanregisterglobals runtime support function, which calls asan runtime function _asan_register_globals to register global variables. 2. Create a new initialization function for the package being compiled. This function initializes an array of instrumented global variables and pass it to function runtime.asanregisterglobals. An instrumented global variable has trailing redzone. 3. Writes the new size of instrumented global variables that have trailing redzones into object file. 4. Notice that the current implementation is only compatible with the ASan library from version v7 to v9. Therefore, using the -asan option requires that the gcc version is not less than 7 and the clang version is less than 4, otherwise a segmentation fault will occur. So this patch adds a check on whether the compiler being used is a supported version in cmd/go. (This is a redo of CL 401775 with a fix for a build break due to an intervening commit that removed the internal/execabs package.) Updates #44853. Change-Id: I719d4ef2b22cb2d5516e1494cd453c3efb47d6c7 Reviewed-on: https://go-review.googlesource.com/c/go/+/403851 Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-05-04Revert "cmd/compile: enable Asan check for global variables"Bryan Mills
This reverts CL 401775. Reason for revert: broke build. Change-Id: I4f6f2edff1e4afcf31cd90e26dacf303979eb10c Reviewed-on: https://go-review.googlesource.com/c/go/+/403981 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2022-05-04cmd/compile: enable Asan check for global variablesfanzha02
With this patch, -asan option can detect the error memory access to global variables. So this patch makes a few changes: 1. Add the asanregisterglobals runtime support function, which calls asan runtime function _asan_register_globals to register global variables. 2. Create a new initialization function for the package being compiled. This function initializes an array of instrumented global variables and pass it to function runtime.asanregisterglobals. An instrumented global variable has trailing redzone. 3. Writes the new size of instrumented global variables that have trailing redzones into object file. 4. Notice that the current implementation is only compatible with the ASan library from version v7 to v9. Therefore, using the -asan option requires that the gcc version is not less than 7 and the clang version is less than 4, otherwise a segmentation fault will occur. So this patch adds a check on whether the compiler being used is a supported version in cmd/go. Updates #44853. Change-Id: Ib877a817209ab2be68a8e22c418fe4a4a20880fc Reviewed-on: https://go-review.googlesource.com/c/go/+/401775 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-29cmd/compile: consistent unified IR handling of package unsafeMatthew Dempsky
Within the unified IR export format, I was treating package unsafe as a normal package, but expecting importers to correctly handle deduplicating it against their respective representation of package unsafe. However, the surrounding importer logic differs slightly between cmd/compile/internal/noder (which unified IR was originally implemented against) and go/importer (which it was more recently ported to). In particular, noder initializes its packages map as `map[string]*types2.Package{"unsafe": types2.Unsafe}`, whereas go/importer initializes it as just `make(map[string]*types.Package)`. This CL makes them all consistent. In particular, it: 1. changes noder to initialize packages to an empty map to prevent further latent issues from the discrepency, 2. adds the same special handling of package unsafe already present in go/internal/gcimporter's unified IR reader to both of cmd/compile's implementations, and 3. changes the unified IR writer to treat package unsafe as a builtin package, to force that readers similarly handle it correctly. Fixes #52623. Change-Id: Ibbab9b0a1d2a52d4cc91b56c5df49deedf81295a Reviewed-on: https://go-review.googlesource.com/c/go/+/403196 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-22Revert "cmd/compile: enable Asan check for global variables"Bryan Mills
This reverts CL 321715. Reason for revert: broke cmd/go.TestScript/install_msan_and_race_require_cgo on several builders. Change-Id: Ia0392de555d6e973960769a0e4709f0193d16706 Reviewed-on: https://go-review.googlesource.com/c/go/+/401755 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2022-04-22cmd/compile: enable Asan check for global variablesfanzha02
With this patch, -asan option can detect the error memory access to global variables. So this patch makes a few changes: 1. Add the asanregisterglobals runtime support function, which calls asan runtime function _asan_register_globals to register global variables. 2. Create a new initialization function for the package being compiled. This function initializes an array of instrumented global variables and pass it to function runtime.asanregisterglobals. An instrumented global variable has trailing redzone. 3. Writes the new size of instrumented global variables that have trailing redzones into object file. 4. Notice that the current implementation is only compatible with the ASan library from version v7 to v9. Therefore, using the -asan option requires that the gcc version is not less than 7 and the clang version is less than 4, otherwise a segmentation fault will occur. So this patch adds a check on whether the compiler being used is a supported version in cmd/go. Change-Id: I664e74dcabf5dc7ed46802859174606454e8f1d3 Reviewed-on: https://go-review.googlesource.com/c/go/+/321715 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-04-04cmd/compile: switch to final unified IR export formatMatthew Dempsky
Now that there's a native go/types importer for unified IR, the compiler no longer needs to stay backwards compatible with old iexport importers. This CL also updates the go/types and go/internal/gcimporter tests to expect that the unified IR importer sets the receiver parameter type to the underlying Interface type, rather than the Named type. This is a temporary workaround until we make a decision on #49906. Notably, this makes `GOEXPERIMENT=unified go test` work on generics code without requiring `-vet=off` (because previously cmd/vet was relying on unified IR's backwards-compatible iexport data, which omitted generic types). Change-Id: Iac7a2346bb7a91e6690fb2978fb702fadae5559d Reviewed-on: https://go-review.googlesource.com/c/go/+/386004 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-04cmd/compile: support reading union type for compiler backend in unified IRCuong Manh Le
Fixes #52124 Change-Id: I5749822d41d8e51f476bceb277b1d2cf7350dcc3 Reviewed-on: https://go-review.googlesource.com/c/go/+/397874 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>
2022-03-18internal/buildcfg: initialize GOROOT to runtime.GOROOTBryan C. Mills
In the beginning the Go compiler was in C, and C had a function 'getgoroot' that returned GOROOT from either the environment or a generated constant. 'getgoroot' was mechanically converted to Go (as obj.Getgoroot) in CL 3046. obj.Getgoroot begat obj.GOROOT. obj.GOROOT begat objabi.GOROOT, which begat buildcfg.GOROOT. As far as I can tell, today's buildcfg.GOROOT is functionally identical to runtime.GOROOT(). Let's reduce some complexity by defining it in those terms. While we're thinking about buildcfg.GOROOT, also check whether it is non-empty: if the toolchain is built with -trimpath, the value of GOROOT might not be valid or meaningful if the user invokes cmd/compile or cmd/link directly, or via a build tool other than cmd/go that doesn't care as much about GOROOT. (As of CL 390024, runtime.GOROOT will return the empty string instead of a bogus one when built with -trimpath.) For #51461. Change-Id: I9fec020d5fa65d4aff0dd39b805f5ca93f86c36e Reviewed-on: https://go-review.googlesource.com/c/go/+/393155 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
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-03-16cmd/compile: detect invalid NIH conversions within unified IRMatthew Dempsky
Unified IR currently relies on typecheck to diagnose invalid //go:notinheap conversions, which prevents removing all of its (otherwise) dead error-reporting code. This CL updates the unified IR reader to instead proactively diagnose these invalid conversions. This logic can be removed again once #46731 is implemented, but in the mean time it allows progress on #51691. Updates #46731. Updates #51691. Change-Id: Ifae81aaad770209ec7a67bc10b55660f291e403e Reviewed-on: https://go-review.googlesource.com/c/go/+/392917 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-03-09cmd/compile: mark instantiated generic functions as DUPOKMatthew Dempsky
Unified IR wasn't marking instantiated generic functions as DUPOK, even though they can appear in multiple compilation units, which evidently interfered with cmd/link's dead code elimination logic. Manually confirmed to fix the issue, but non-trivial to test within $GOROOT/test currently, because it's only reproducible when cmd/compile is invoked with -p. @rsc is currently investigating updating test/run.go appropriately, after which I'll revisit writing a test case. Fixes #51519. Change-Id: I74a79ed0ca15b25b826e419714af5ceb6e567012 Reviewed-on: https://go-review.googlesource.com/c/go/+/390956 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2022-03-07cmd/compile: remove duplicate const logic from typecheckMatthew Dempsky
Now that we always use types2 to validate user source code, we can remove the constSet logic from typecheck for detecting duplicate expression switch cases and duplicate map literal keys. This logic is redundant with types2, and currently causes unified IR to report inappropriate duplicate constant errors that only appear after type substitution. Updates #42758. Change-Id: I51ee2c5106eec9abf40eba2480dc52603c68ba21 Reviewed-on: https://go-review.googlesource.com/c/go/+/390474 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2022-03-07cmd/compile: add itabs to unified IR dictionariesMatthew Dempsky
This CL changes unified IR to include itabs in its serialized dictionary format. Change-Id: I334c972dc1bc19293f955bb23cfb66844da7adec Reviewed-on: https://go-review.googlesource.com/c/go/+/390355 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-03-07cmd/compile: represent derived types with ir.DynamicType in unified IRMatthew Dempsky
This CL switches unified IR to using ir.DynamicType for derived types. This has an immediate effect of fixing compilation of generic code that when fully stenciled results in statically invalid type assertions. This does require updating typecheck to expect ODYNAMICTYPE in type switches, but this is straightforward to implement. For now, we still statically resolve the runtime type (or itab) pointer. However, a subsequent CL will allow reading these pointers from the runtime dictionary. Change-Id: I1666678fcc588bc9cb8b97871bd02b9059848e6d Reviewed-on: https://go-review.googlesource.com/c/go/+/390336 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-03-07cmd/compile: fix reentrancy issue in unified IR function body readingMatthew Dempsky
We shouldn't need to read in function bodies for new functions found during inlining, but something is expecting them to still be read in. We should fix that code to not depend on them being read in, but in the mean time reading them in anyway is at least correct, albeit less efficient in time and space. Fixes #49536. Updates #50552. Change-Id: I949ef45e7be09406e5a8149e251d78e015aca5fa Reviewed-on: https://go-review.googlesource.com/c/go/+/390335 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-01cmd/compile/internal/ir: remove unused -G=0 node typesMatthew Dempsky
ir.PkgName was only used by the old -G=0 frontend for representing identifiers that refer to a package name. The new types2-based frontends directly resolve the qualified identifier to the respective object during IR construction. Similarly, most of the ir.*Type nodes were only needed for representing types in the IR prior to type checking. The new types2-based frontends directly construct the corresponding types.Type instead. Exception: The internal typecheck.DeclFunc API used for compiler-generated functions still depends on ir.FuncType, so that IR node type is retained for now. (Eventually, we should update typecheck.DeclFunc and callers to not depend on it, but it's not urgent.) Change-Id: I982f1bbd41eef5b42ce0f32676c7dc4a8ab6d0ee Reviewed-on: https://go-review.googlesource.com/c/go/+/388538 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2022-03-01cmd/compile: unified IR support for implicit interfacesMatthew Dempsky
Change-Id: Ibdaa0750f7bc47b513c047fdf4b7145ebba9e870 Reviewed-on: https://go-review.googlesource.com/c/go/+/386001 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com>
2022-03-01internal/pkgbits: extract unified IR coding-level logicMatthew Dempsky
This logic is needed for the go/types unified IR importer, so extract it into a separate internal package so we can reuse a single copy. Change-Id: I5f734b76e580fdb69ee39e45ac553c22d01c5909 Reviewed-on: https://go-review.googlesource.com/c/go/+/386000 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com>
2022-03-01cmd/compile: remove unified IR quirks modeMatthew Dempsky
Unified IR quirks mode existed to help bootstrap unified IR by forcing it to produce bit-for-bit identical output to the original gc noder and typechecker. However, I believe it's far enough along now to stand on its own, plus we have good test coverage of generics already for -G=3 mode. Change-Id: I8bf412c8bb5d720eadeac3fe31f49dc73679da70 Reviewed-on: https://go-review.googlesource.com/c/go/+/385998 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>
2021-12-15all: fix typo in commentichxxx
Remove duplicate 'the' Change-Id: I3ed81c8d9c488662387e45580a3bcd462448ba44 GitHub-Last-Rev: 86443993b9b58c6fce4e09e283604c32ccc44cec GitHub-Pull-Request: golang/go#50017 Reviewed-on: https://go-review.googlesource.com/c/go/+/372394 Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-10-25cmd/compile/internal/typecheck: record whether an interface is implicitRobert Findley
In preparation for capturing the implicit interface bit in export data, thread through the IsImplicit property from types2 into typecheck. Change-Id: I9b46fe73de102935a127e6ececaacd76738b557e Reviewed-on: https://go-review.googlesource.com/c/go/+/357109 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-09-09cmd/compile: fix unified IR panic when expanding nested inline functionCuong Manh Le
When reading body of inlining function, which has another inlined function in the body, the reader still add this inlined function to todoBodies, which it shouldn't because the inlined function was read already. To fix this, introduce new flag to signal that we are done construting all functions in todoBodies, thus the addBody shouldn't add anything to todoBodies then. Updates #48094 Change-Id: I45105dd518f0a7b69c6dcbaf23b957623f271203 Reviewed-on: https://go-review.googlesource.com/c/go/+/347529 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-09-09cmd/compile: remove 'ext' fields from unified IR reader/writer typesMatthew Dempsky
This is a vestigial artifact of how I initially split apart the public and private data for objects. But now objects are split into more parts, and it's proven easier to just keep them as separate variables. So it's time to cleanup the initial public/private code to follow the same approach. Change-Id: I3976b19fb433cbe21d299d3799ec616f9e59561e Reviewed-on: https://go-review.googlesource.com/c/go/+/348412 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-09-09cmd/compile: simplify value coding for unified IRMatthew Dempsky
In indexed export, values are always exported along with their type and are encoded in a type-sensitive manner, because this matches how cmd/compile handled constants internally. However, go/types intentionally differs from this, decoupling type from value representation. As unified IR strives to be more go/types-centric, it makes sense to embrace this and make values a more first-class encoding. Change-Id: If21d849c4f610358bd776d5665469d180bcd5f6e Reviewed-on: https://go-review.googlesource.com/c/go/+/348014 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-09-09cmd/compile: extrapolate $GOROOT in unified IRMatthew Dempsky
This ensures that diagnostics for files within $GOROOT continue to be reported using their full filepath, rather than the abbreviated filepath. Notably, this is necessary for test/run.go, which has tests that expect to see the full filepath. Updates #48247. Change-Id: I440e2c6dd6109ca059d81cee49e476bba805d703 Reviewed-on: https://go-review.googlesource.com/c/go/+/348670 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-09-01cmd/compile: optimize unified IR handling of imported functionsMatthew Dempsky
This CL skips reading of imported function bodies except from the local package or for inlining. Previously, we wasted a bunch of CPU and memory by reading in normal function bodies for all imported functions and methods. Change-Id: I0b3df3f4a3e2819117dac11a1f9e4526288c14d8 Reviewed-on: https://go-review.googlesource.com/c/go/+/347030 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-09-01cmd/compile: emit unified IR wrappers after inliningMatthew Dempsky
This CL delays unified IR's wrapper generation to after inlining. Change-Id: Idfe496663489d6b797a647eb17200c6322d0334a Reviewed-on: https://go-review.googlesource.com/c/go/+/347029 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-08-31cmd/compile: make unified IR more selective about method wrappersMatthew Dempsky
This CL makes two changes to how unified IR emits method wrappers: 1. It no longer emits wrappers for defined types' underlying types. Previously, a declaration like `type T struct { U }` would emit wrappers for both `T` and `struct { U }`. Now they're only emitted for `T`. 2. It emits method value wrappers only when OMETHVALUE nodes are actually created, like how -G=0 works. Method values are relatively rare, aren't needed for runtime type descriptors (unlike method expression wrappers), and large projects end up spending a non-trivial amount of time compiling these unneeded wrappers. Change-Id: I21da97df3132ec12cc67debf62b5b2d282f481cf Reviewed-on: https://go-review.googlesource.com/c/go/+/346230 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-08-26cmd/compile: move types init code into package typesMatthew Dempsky
This moves the package types setup code from package typecheck into package types itself. This is a prereq for making types.Type more opaque, because some unit tests depend on being able to init the basic universal types. A few notable details of this CL: 1. Creating the builtin types requires being able to create the ir.Name/ir.OTYPE that represents it, but package types can't depend on package ir. So we add a callback function to handle creating the ir.Name. 2. This CL moves ir.Pkgs.Unsafe to types.UnsafePkg. Package unsafe is part of the language, not like the other ir.Pkgs packages that are purely implementation details. 3. This CL also moves typecheck.FakeRecv to types.FakeRecv, addressing an outstanding TODO. Change-Id: I64de04ce82fbcd1bb59f547e2eea3cda52d89429 Reviewed-on: https://go-review.googlesource.com/c/go/+/345474 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-08-20cmd/compile/internal/syntax: add PosBase.TrimmedMatthew Dempsky
With types2, some syntax.PosBases need to be constructed from export data, which must only contain "trimmed" filenames (i.e., that they've already been made absolute and undergone -trimpath processing). However, it's not safe to apply trimming to a filename multiple times, and in general we can't distinguish trimmed from untrimmed filenames. This CL resolves this by adding a PosBase.Trimmed boolean so we can distinguish whether the associated filename has been trimmed yet. This is a bit hacky, but is the least bad solution I've come up with so far. This unblocks enabling -G=3 by default. Change-Id: I7383becfb704680a36f7603e3246af38b21f100b Reviewed-on: https://go-review.googlesource.com/c/go/+/343731 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Trust: Dan Scales <danscales@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-08-03[dev.typeparams] cmd/compile: avoid redundant method wrappers in unified IRMatthew Dempsky
Currently, unified IR takes a simple approach of generating method wrappers for every anonymous type that it sees. This is correct, but spends a lot of time in code generation and bloats the object files with duplicate method wrappers that the linker discards. This CL changes it to distinguish anonymous types that were found in imported packages vs the local package. The simple win here is that now we stop emitting wrappers for imported types; but by keeping track of them and marking them as "have" instead of "need", we can avoid emitting wrappers for types that appear in both the local package and imported packages. This can be improved further, but this is a simple first step that prevents large protobuf projects from blowing up build cache limits. Change-Id: Ia65e8981cb1f067eca2bd072b9bbb77c27b95207 Reviewed-on: https://go-review.googlesource.com/c/go/+/339411 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-08-03[dev.typeparams] cmd/compile: set sym.Def to ir.Name for method value wrappersMatthew Dempsky
The code for generating method value wrappers is weird that it sets sym.Def to the generated ir.Func, whereas normally sym.Def points to ir.Name. While here, change methodValueWrapper to return the ir.Name too, since that's what the caller wants. Change-Id: I3da5320ca0bf4d32d7b420345454f19075d19a26 Reviewed-on: https://go-review.googlesource.com/c/go/+/339410 Trust: Matthew Dempsky <mdempsky@google.com> Trust: Cuong Manh Le <cuong.manhle.vn@gmail.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-07-26[dev.typeparams] cmd/compile: fix unified IR support for //go:nointerfaceMatthew Dempsky
This CL changes fixedbugs/issue30862.go into a "runindir" test so that it can use '-goexperiment fieldtrack' and test that //go:nointerface works with cmd/compile. In particular, this revealed that -G=3 and unified IR did not handle it correctly. This CL also fixes unified IR's support for //go:nointerface and adds a test that checks that //go:nointerface, promoted methods, and generics all interact as expected. Updates #47045. Change-Id: Ib8acff8ae18bf124520d00c98e8915699cba2abd Reviewed-on: https://go-review.googlesource.com/c/go/+/332611 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-07-21[dev.typeparams] cmd/compile: cleanup unified IR file format a littleMatthew Dempsky
This CL makes two changes: 1. It moves object symbols and code tags into a new "relocName" relocation, which should eventually allow getting rid of objStub. 2. It moves the type parameter data into the relocObjDict relocation, so everything related to writing out dictionaries is contained there. Change-Id: If0f7ff7d9384e8664957c3180bf6f20e97bcff6e Reviewed-on: https://go-review.googlesource.com/c/go/+/336051 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-07-14[dev.typeparams] cmd/compile: record more typ/fun info for dictionaries in ↵Matthew Dempsky
unified IR Records whether a derived type is needed at run-time as well as instantiated functions that rely on derived types (and thus need sub-dictionaries). Change-Id: I2f2036976bfce5b3b4372fba88b4116dafa7e6b7 Reviewed-on: https://go-review.googlesource.com/c/go/+/334349 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-07-14[dev.typeparams] cmd/compile: handle objStub earlier in readerMatthew Dempsky
There's no point in reading the object dictionary for a stub declaration. Only the package that contains the full object definition will contain an object dictionary. Change-Id: I458b77d20745105bf46190ef552312bdb5ca4d06 Reviewed-on: https://go-review.googlesource.com/c/go/+/334409 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-07-11[dev.typeparams] cmd/compile: slightly more incremental unified typecheckMatthew Dempsky
This CL pushes the typecheck.Expr calls further down to the IR construction points. It turns out we don't really care about typecheck.AssignExpr, because it's only used to distinguish whether ir.BlankNode is allowed. We can avoid that issue by just skipping the call to typecheck.Expr for blank nodes. Similarly, for typecheck.Callee, only two details matter: (1) don't report errors for builtin functions (which aren't allowed outside of callee contexts); and (2) method-value selector expressions need to have Op ODOTMETH/ODOTINTER rather than OMETHVALUE. The first can be handled by simply skipping typecheck on Names (as with ir.BlankNode, we don't need to typecheck these). The second currently requires adding a 'callee bool' parameter to disambiguate the context. The other option would be for exprCall to reset the fun's Op from OMETHVALUE to OXDOT and let typecheck handle it a second time. But I anticipate needing to add extra logic in the exprSelector case which would be harder to undo, so this seems somewhat better. Change-Id: I1a8dfb6af04265ab466fd7f4cb6ee8b479e92282 Reviewed-on: https://go-review.googlesource.com/c/go/+/333769 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-07-10[dev.typeparams] cmd/compile: more incremental typecheck for unified IRMatthew Dempsky
CL 332469 changed the unified IR reader to incrementally typecheck each statement as they're read/constructed. This CL goes further to incrementally typecheck each expression. While here, this CL reorganizes a few things to make this go more smoothly. In particular, it renames expr to expr0 and adds a new expr wrapper that applies typecheck.Expr; gets rid of exprTypeSwitchguard by moving that logic into switchStmt; and splits exprConvert out from exprCall, which simplifies the logic for typechecking the calleee expression somewhat. Change-Id: I6289de9388dc94a947971f4b7213aafeb2faa5dc Reviewed-on: https://go-review.googlesource.com/c/go/+/333730 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-07-04[dev.typeparams] cmd/compile: better Call constructorMatthew Dempsky
Historically, it's been tedious to create and typecheck ir.OCALL nodes, except by handing them off entirely to typecheck. This is because typecheck needed context on whether the call is an expression or statement, and to set flags like Func.ClosureCalled and CallExpr.Use. However, those flags have now been removed entirely by recent CLs, so we can instead just provide a better typecheck.Call function for constructing and typechecking arbitrary call nodes. Notably, this simplifies things for unified IR, which can now incrementally typecheck call expressions as it goes without worrying about context. Change-Id: Icbdc55c3bd8be84a242323bc45006f9dec09fdcd Reviewed-on: https://go-review.googlesource.com/c/go/+/332692 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-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: flatten OINLCALL in walkMatthew Dempsky
Inlining replaces inlined calls with OINLCALL nodes, and then somewhat clumsily tries to rewrite these in place without messing up order-of-evaluation rules. But handling these rules cleanly is much easier to do during order, and escape analysis is the only major pass between inlining and order. It's simpler to teach escape analysis how to analyze OINLCALL nodes than to try to hide them from escape analysis. Does not pass toolstash -cmp, but seems to just be line number changes. Change-Id: I1986cea39793e3e1ed5e887ba29d46364c6c532e Reviewed-on: https://go-review.googlesource.com/c/go/+/332649 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-07-03[dev.typeparams] cmd/compile: formalize "hidden parameters" ideaMatthew Dempsky
This CL formalizes the closure-var trick used for method-value wrappers to be reusable for defining other functions that take hidden parameters via the closure-context register. In particular, it: 1. Adds a new ir.NewHiddenParam function for creating hidden parameters. 2. Changes ir.NewClosureVar to copy Type/Typecheck from the closure variable, so that callers can needing to manually copy these. 3. Updates existing code accordingly (i.e., method-value wrappers to start using ir.NewHiddenParam, and closure builders to stop copying types). Longer term, I anticipate using this to pass dictionaries to stenciled functions within unified IR. Change-Id: I9da3ffdb2a26d15c6e89a21b4e080686d6dc872c Reviewed-on: https://go-review.googlesource.com/c/go/+/332612 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-07-02[dev.typeparams] cmd/compile: incremental typecheck during unified IRMatthew Dempsky
This CL changes unified IR to incrementally typecheck the IR as it's constructed. This is significant, because it means reader can now use typecheck.Expr to typecheck sub-expressions when it's needed. This should be helpful for construction and insertion of dictionaries. This CL does introduce two quirks outside of unified IR itself, which simplify preserving binary output: 1. Top-level declarations are sorted after they're constructed, to avoid worrying about the order that closures are added. 2. Zero-padding autotmp_N variable names. Interleaving typechecking means autotmp variables are sometimes named differently (since their naming depends on the number of variables declared so far), and this ensures that code that sorts variables by names doesn't suddenly sort autotmp_8/autotmp_9 differently than it would have sorted autotmp_9/autotmp_10. While at it, this CL also updated reader to use ir.WithFunc instead of manually setting and restoring ir.CurFunc. There's now only one remaining direct use of ir.CurFunc. Change-Id: I6233b4c059596e471c53166f94750917d710462f Reviewed-on: https://go-review.googlesource.com/c/go/+/332469 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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 22:13:36 +0000