aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder
AgeCommit message (Collapse)Author
38 hourscmd/compile: remove redundant codeWeixie Cui
Change-Id: If524465cc898a36a31f9034d5b2f13e8842357a9 GitHub-Last-Rev: bdf52219d7d38b94213529f3d399acca69fa5bae GitHub-Pull-Request: golang/go#78604 Reviewed-on: https://go-review.googlesource.com/c/go/+/764361 Reviewed-by: Mark Freeman <markfreeman@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: Keith Randall <khr@google.com>
4 dayscmd/compile/internal/noder: revert to UIR V3Mark Freeman
Upgrading to V4 early doesn't seem to make much sense while we refine things. Any change to encoding would require another version gate and propagation; this gets tedious fast. Instead, let's keep on V3 and test locally with V4. We can commit skipped tests as we refine and then turn them all on *with* the bump up to V4. Change-Id: I571715e5da75095612f68b224c82e6d22ad3ab25 Reviewed-on: https://go-review.googlesource.com/c/go/+/765444 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com>
7 dayscmd/compile/internal/noder: use UIR V4Mark Freeman
Change-Id: If8acdbf0e48ed600c4ba3f762802879335df1465 Reviewed-on: https://go-review.googlesource.com/c/go/+/761980 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
11 dayscmd/compile/internal/noder: recognize generic method instantiationMark Freeman
This change slightly extends expression traversal to recognize explicit instantiation of generic methods. The relevant MethodVal and MethodExpr snippets are extracted into helper functions, since they are needed in two places. Change-Id: I85d49d89f2422fa4c2d09de28fb6552f171a2a1f Reviewed-on: https://go-review.googlesource.com/c/go/+/762560 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
12 dayscmd/compile/internal/noder: omit wrapper functions for generic methodsMark Freeman
Emitting wrapper functions for generic methods is tricky for 2 reasons: 1. Existing downstream machinery expects that it can make certain assumptions about a method if it sees a wrapper function. We may violate those assumptions with generic method wrappers. 2. Signatures for generic methods are generic and hence cannot be encoded using w.typ. This has the slight downside of not using a statically computed wrapper for generic methods and instead dynamically computing the dictionary pointer. Thus, we miss out on a performance optimization for generic methods for now. Code that does not use generic methods is unaffected. Change-Id: I72c626ef0f807c0cb54d8cf040250de8177303cc Reviewed-on: https://go-review.googlesource.com/c/go/+/762382 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
12 dayscmd/compile/internal/noder: set dict.receivers in writerMark Freeman
Change-Id: I9846b8086bacbc69e438a8e39e3e26c46316fb08 Reviewed-on: https://go-review.googlesource.com/c/go/+/762022 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com>
12 dayscmd/compile/internal/noder: offset type parameter indicesMark Freeman
When a writer goes to encode use of a type parameter, it only records an index because the writer knows all of the type parameters in scope for that object. The writer orders the type parameteres as implicits first, then receivers, then explicits actually on the object. Note that receivers *are* explicit type arguments, they're just inherited from the type. For instance, given: func (T[P]) m[Q, R any]() This has: - 0 implicits - 1 receiver - 2 explicits With this ordering, P is at 0, Q is at 1, and R is at 2. In contrast, inspecting TypeParam.index for Q yields 0, and for R yields 1; hence the offset is needed. Change-Id: If12f342e109fbc5935ba278f574ac2809c889335 Reviewed-on: https://go-review.googlesource.com/c/go/+/762021 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
12 dayscmd/compile/internal/noder: decode generic methods and pipe receiversMark Freeman
Change-Id: I7a66fba400a743f4ef2fb989cd8e74e955e22b0f Reviewed-on: https://go-review.googlesource.com/c/go/+/762020 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
13 dayscmd/compile/internal/noder: add encoding for generic methodsMark Freeman
We have not yet added the decoding on the reader side. Change-Id: Ic7f8dc51b6b9a2c214b402b1314ee84c0085c16a Reviewed-on: https://go-review.googlesource.com/c/go/+/761983 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com>
13 dayscmd/compile/internal/noder: split up objTypeParamsMark Freeman
This splits objTypeParams into objTypeParams and objRecvTypeParams. The type parameters on a generic method and its receiver need to be reported separately to the reader. Change-Id: If9eb93ca66a5a5e4bdce71364627ff4bee110311 Reviewed-on: https://go-review.googlesource.com/c/go/+/761981 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
14 dayscmd/compile, cmd/link: add linknamestd directive for std-only linknamesCherry Mui
In the standard library, there are a number of linknames, for sharing symbols within the standard library. They are not supposed to be accessed externally. But currently there is no good mechanism to prevent that. In the linker we have a blocklist of linknames, which forbids linkname references other than explicitly allowed packages. The blocklist is manually maintained, requiring periodic manual update. To move away from that manually maintained blocklist, this CL introduces a new directive, linknamestd, that marks a linkname for use within the standard library only. The linker will allow references within the standard library and forbid others. For a proof of concept, runtime.coroswitch is removed from the blocklist, and replaced with linknamestd. An external reference to it is still disallowed by the linker, as tested with cmd/link.TestCheckLinkname with testdata/linkname/coro.go. Change-Id: I0d0f8746b8835d8cdcfc3ff835d22a551da5f038 Reviewed-on: https://go-review.googlesource.com/c/go/+/749942 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
14 dayscmd/compile/internal/noder: separate generic methods in type encodingMark Freeman
This doesn't need a version guard here because we will bump the version in Go 1.27. It will be impossible to witness a generic method at the UIR layer without being at an appropriate bitstream version. Change-Id: Ie6c89fb98d55a3dccbd53e87860d6103582a921e Reviewed-on: https://go-review.googlesource.com/c/go/+/761582 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-31cmd/compile/internal/noder: encode dictionaries for generic methodsMark Freeman
Generic methods have 2 sources of explicit type arguments-the receiver and the method itself. We simply concatenate these lists when constructing the dictionary. Change-Id: I8ba99fa7274b594941867e9bf6c2a22356c03e46 Reviewed-on: https://go-review.googlesource.com/c/go/+/761341 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-31cmd/compile/internal/noder: mangle method namesMark Freeman
Mangling produces shaped qualified identifiers using a dictionary. It's important for determining the stenciled type to use for a given instantiation. Since generic methods have qualified identifiers, they need mangling. Suppose a generic method like T[P].m[Q] and a shaped dictionary like: { implicits: 0 receivers: 1 targs: [go.shape.int, go.shape.int] } This would be shaped to T[go.shape.int].m[go.shape.int]. Change-Id: Idc4c825f77a4e9209da65b5b0acb74b9f845bde7 Reviewed-on: https://go-review.googlesource.com/c/go/+/761340 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-31cmd/compile/internal/noder: qualify identifiers for generic methodsMark Freeman
Generic methods will be hoisted to objects so that they can get their own dictionaries. We need to avoid name collisions, so within a package, we qualify generic methods using their defining type. We don't differentiate method identifiers by whether they have a pointer or value receiver for simplicity. Change-Id: Ied06c5e4a4c5a6f8de8027358ddbe38fc40ae452 Reviewed-on: https://go-review.googlesource.com/c/go/+/761263 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-31cmd/compile/internal/noder: method expressions have nil implicitsMark Freeman
Change-Id: Ia7ba5484ef5258cc8edc19b7d500e334c0e0365d Reviewed-on: https://go-review.googlesource.com/c/go/+/761261 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-31cmd/compile/internal/noder: method expressions for generic methodsMark Freeman
This change permits shaping method expressions for generic methods. The API is slightly different for generic and non-generic methods, as explained in code comments. Using OMETHEXPR minimizes the necessary changes, but forces us to split / rejoin the linker symbol for generic methods. While a bit odd, it seems sound. Change-Id: Iff28b9b11b9e83f450225aba0873644633f20633 Reviewed-on: https://go-review.googlesource.com/c/go/+/761220 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-30cmd/compile/internal/noder: swap use of TypeList for []TypeMark Freeman
The noder will need to manipulate type argument lists. Because it is outside types2, it needs exported APIs to do so, which then must also be reflected in go/types. We don't want APIs which only the noder cares about to be surfaced so broadly. It might be better for the noder to use its own representation for type lists; a []Type is fine for now. Change-Id: Ia0917a6d26e00218fc9ccfd443d8d07224b1db5d Reviewed-on: https://go-review.googlesource.com/c/go/+/760360 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-30cmd/compile/internal/noder: add is[Concrete|Generic]Method helpersMark Freeman
The isGenericMethod helper will be necessary for upcoming changes to UIR, though it's not currently used. Since all generic methods are concrete methods, we also define the isConcreteMethod helper to illustrate the subset relationship between the two classes of methods. We use this helper for encoding method dictionaries. Change-Id: Ib7cdd7224fc733553726c8f86c0fe59ad60bff67 Reviewed-on: https://go-review.googlesource.com/c/go/+/759781 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-26cmd/compile/internal/noder: set hasShape for shaped functionsMark Freeman
A signature with a shape will be overwritten using shapeSig, but it arguably still has a shape because it's using a shaped dictionary. This mimics the approach for ObjType. Change-Id: I4646cd73129606772a9218662de76a37217366b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/759721 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-26cmd/compile/internal/noder: shapeSig must return shaped signaturesMark Freeman
Suppose a signature f[P any]() shaped to f[go.shape.int](). This function does not flag f[go.shape.int]() as having a shape because it does not mention a shaped type in its parameter or return fields. This doesn't seem right. Change-Id: I87c4e3b259328b7d27ff0a98d65ed400b4895a69 Reviewed-on: https://go-review.googlesource.com/c/go/+/759660 Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-26cmd/compile: skip incomplete types in needWrapperCuong Manh Le
A recursive pointer type *T may still be a TFORW when the compiler determines if method wrappers are needed. This leads to an incorrect decision and triggers an internal compiler error. Fix this by skipping incomplete types during the method wrapper generation check. Fixes #78295 Change-Id: I4005e525e9b076c6656aed5419283c0418edcac6 Reviewed-on: https://go-review.googlesource.com/c/go/+/758922 Reviewed-by: Jakub Ciolek <jakub@ciolek.dev> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-03-20cmd/compile/internal/noder: don't shoot oneself (fix silly mistake)Robert Griesemer
When reading multiple promoted fields in a struct literal from UIR, don't overwrite the (top-level) struct literal type needed for the next field. Fixes #78262. For #9859. Change-Id: Ifac64537bebcb7dbb79a6173d0cd032cbf0b8ed8 Reviewed-on: https://go-review.googlesource.com/c/go/+/757225 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2026-03-19cmd/compile: enable promoted field selectors as keys in struct literalsRobert Griesemer
Switch the generated UIR version from V2 to V3. Adjust cmd/compile/internal/types to accept promoted field selectors in composite literals. Fixes #9859. Change-Id: Ie314e28567cfa6cf4c9e962a07b32dd05b06bf5e Reviewed-on: https://go-review.googlesource.com/c/go/+/755740 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2026-03-19cmd/compile/internal/noder: encode promoted struct fields for composite ↵Robert Griesemer
literals in UIR This change requires an encoding format change for struct literals. Introduce a new UIR version (V3) and use the opportunity to encode all composite literals more compactly: specifically, when we know that (composite literal) keys are always present, avoid encoding a bool value for each key. Do not yet enable the new format. For #9859. Change-Id: Ic6dc9adb1aa494e923eadaf578f8cfc61efd5ea4 Reviewed-on: https://go-review.googlesource.com/c/go/+/754664 Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-16cmd/compile/internal/noder: factor out common UIR versionRobert Griesemer
Ensure that the writers and readers use the same UIR version by defining the currently used version in one place rather than setting it in two places which might diverge. Change-Id: Iae139e08c3c01e553250ba6f4f171132b06eb8c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/754662 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
2026-03-10cmd/compile: remove loop variable capture workaroundsgojkovicmatija99
Since Go 1.22, loop variables have per-iteration scope, making the x := x this pattern unnecessary for goroutine capture. No issue required for this trivial cleanup. Change-Id: I00d98522537fc2b9a6b4d598c8aa21b447628d41 Reviewed-on: https://go-review.googlesource.com/c/go/+/753400 Auto-Submit: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-06cmd/compile: use tail calls for wrappers for embedded interfacesKeith Randall
type I interface { foo() } type S struct { I } Because I is embedded in S, S needs a foo method. We generate a wrapper function to implement (*S).foo. It just loads the embedded field I out of S and calls foo on it. When the thing in S.I itself needs a wrapper, then we have a wrapper calling another wrapper. This can continue, leaving a potentially long sequence of wrappers on the stack. When we then call runtime.Callers or friends, we have to walk an unbounded number of frames to find a bounded number of non-wrapper frames. This really happens, for instance with I = context.Context, S = context.ValueCtx, and runtime.Callers = pprof sample (for any of context.Context's methods). To fix, make the interface call in the wrapper a tail call. That way, the number of wrapper frames on the stack does not increase when there are lots of wrappers happening. Fixes #75764 Fixes #77781 Change-Id: I03b1731159d9218c7f14f72ecbbac822d6a6bb87 Reviewed-on: https://go-review.googlesource.com/c/go/+/751465 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2026-01-23cmd/compile: fix loopvar version detection with line directivesxieyuschen
The Go loop variable semantics changed in Go 1.22: loop variables are now created per-iteration instead of per-loop. The compiler decides which semantics to use based on the Go version in go.mod. When go.mod specifies go 1.21 and the code is built with a Go 1.22+ compiler, the per-loop(compatible behavior) semantics should be used. However, when a line directive is present in the source file, go.mod 1.21 and go1.22+ compiler outputs a per-iteration semantics. For example, the file below wants output 333 but got 012. -- go.mod -- module test go 1.21 -- main.go -- //line main.go:1 func main() { var fns []func() for i := 0; i < 3; i++ { fns = append(fns, func() { fmt.Print(i) }) } for _, fn := range fns { fn() } } The distinctVars function uses stmt.Pos().Base() to look up the file version in FileVersions. Base() returns the file name after line directives are applied (e.g., "main.go" for "//line main.go:1"), not the actual source file path. This causes the version lookup to fail for files with line directives. This CL fixes the bug by using stmt.Pos().FileBase() instead. FileBase() returns the actual file path before line directives are applied, ensuring the correct version information is retrieved from the original source file. Fixes: #77248 Change-Id: Idacc0816d112ee393089262468a02acfe40e4b72 Reviewed-on: https://go-review.googlesource.com/c/go/+/737820 Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-01-22go/types, types2: remove support for gotypesalias GODEBUG flagRobert Griesemer
For #76472. Change-Id: Ia51b41639637b1de916625e73c26f625382be305 Reviewed-on: https://go-review.googlesource.com/c/go/+/736441 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Commit-Queue: Robert Griesemer <gri@google.com>
2026-01-22cmd/compile: speedup large init function compile timeCuong Manh Le
Fixes #77153 Change-Id: Ia3906e4d686281be78b65daf7a7a4fd1b2b2483d Reviewed-on: https://go-review.googlesource.com/c/go/+/737880 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2025-11-11std,cmd: go fix -any std cmdAlan Donovan
This change mechanically replaces all occurrences of interface{} by 'any' (where deemed safe by the 'any' modernizer) throughout std and cmd, minus their vendor trees. Since this fix is relatively numerous, it gets its own CL. Also, 'go generate go/types'. Change-Id: I14a6b52856c3291c1d27935409bca8d5fd4242a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/719702 Commit-Queue: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Alan Donovan <adonovan@google.com>
2025-10-21all: eliminate unnecessary type conversionsJes Cok
Found by github.com/mdempsky/unconvert Change-Id: I88ce10390a49ba768a4deaa0df9057c93c1164de GitHub-Last-Rev: 3b0f7e8f74f58340637f33287c238765856b2483 GitHub-Pull-Request: golang/go#75974 Reviewed-on: https://go-review.googlesource.com/c/go/+/712940 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
2025-10-08cmd/compile/internal/devirtualize: improve concrete type analysisMateusz Poliwczak
This change improves the concrete type analysis in the devirtualizer, it not longer relies on ir.Reassigned, it now statically tries to determine the concrete type of an interface, even when assigned multiple times, following type assertions and iface conversions. Alternative to CL 649195 Updates #69521 Fixes #64824 Change-Id: Ib1656e19f3619ab2e1e6b2c78346cc320490b2af GitHub-Last-Rev: e8fa0b12f0a7b1d7ae00e5edb54ce04d1f702c09 GitHub-Pull-Request: golang/go#71935 Reviewed-on: https://go-review.googlesource.com/c/go/+/652036 Reviewed-by: Michael Pratt <mpratt@google.com> 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: Keith Randall <khr@golang.org>
2025-09-26cmd/compile: fix ICE with new(<untyped expr>)Cuong Manh Le
Fixes #75617 Change-Id: Iaee7d4556db54b9999f5ba8458e7c05c11ccfc36 Reviewed-on: https://go-review.googlesource.com/c/go/+/707075 Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2025-09-23cmd/compile/internal: support new(expr)Alan Donovan
This CL adds compiler support for new(expr), a feature of go1.26 that allows the user to specify the initial value of the variable instead of its type. Also, a basic test of dynamic behavior. See CL 704737 for spec change and CL 704935 for type-checker changes. For #45624 Change-Id: I65d27de1ee3aabb819b57cce8ea77f3073447757 Reviewed-on: https://go-review.googlesource.com/c/go/+/705157 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com> Auto-Submit: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2025-09-23cmd/compile: fix typo in commentmohanson
Fix typo for omitted. Change-Id: Ia633abe7f3d28f15f1f538425cdce9e6d9ef48c0 Reviewed-on: https://go-review.googlesource.com/c/go/+/705735 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
2025-09-23cmd/compile: prevent shapifying of pointer shape typeCuong Manh Le
CL 641955 changes the Unified IR reader to not doing shapify when reading reshaping expression, prevent losing of the original type. This is an oversight, as the main problem isn't about shaping during the reshaping process itself, but about the specific case of shaping a pointer shape type. This bug occurs when instantiating a generic function within another generic function with a pointer shape type as type parameter, which will convert `*[]go.shape.T` to `*go.shape.uint8`, resulting in the loss of the original expression's type. This commit changes Unified IR reader to avoid pointer shaping for `*[]go.shape.T`, ensures that the original type is preserved when processing reshaping expressions. Updates #71184 Updates #73947 Fixes #74260 Fixes #75461 Change-Id: Icede6b73247d0d367bb485619f2dafb60ad66806 Reviewed-on: https://go-review.googlesource.com/c/go/+/704095 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2025-08-12all: delete aliastypeparams GOEXPERIMENTCherry Mui
Always enable aliastypeparams and remove the GOEXPERIMENT. Change-Id: Ic38fe25b0bba312a7f83f7bb94b57ab75ce0f0c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/691956 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-08-05cmd: remove dead codeqiulaidongfeng
Fixes #74076 Change-Id: Icc67b3d4e342f329584433bd1250c56ae8f5a73d Reviewed-on: https://go-review.googlesource.com/c/go/+/690635 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Commit-Queue: Alan Donovan <adonovan@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-06-09cmd/compile: relax reshaping conditionCuong Manh Le
CL 641955 changes the Unified IR reader to not doing shapify when reading reshaping expression. However, this condition only matters with pointer type shaping, which will lose the original type, causes the reshaping ends up with a completely different type. This CL relaxes the condition, always allow non-pointer types shaping. Updates #71184 Fixes #73947 Change-Id: Ib0bafd8932c52d99266f311b6cbfc75c00383f9b Reviewed-on: https://go-review.googlesource.com/c/go/+/678335 Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-06-04Revert "cmd/compile: Enable inlining of tail calls"Cherry Mui
This reverts CL 650455 and CL 655816. Reason for revert: it causes #73747. Properly fixing it gets into trickiness with defer/recover, wrapper, and inlining. We're late in the Go 1.25 release cycle. Fixes #73747. Change-Id: Ifb343d522b18fec3fec73a7c886678032ac8e4df Reviewed-on: https://go-review.googlesource.com/c/go/+/678575 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2025-06-04cmd/compile: better error message when import embed packageqiulaidongfeng
Fixes #73955 Change-Id: I7cf3ab4c70dc2e2765b54b88ae8cfc77a3073344 Reviewed-on: https://go-review.googlesource.com/c/go/+/678355 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-06-02cmd/compile/internal/noder: document quirk of string elementsMark Freeman
Change-Id: Ifc3bf896aaaf7c6ce06a01e3dd43780d203638cf Reviewed-on: https://go-review.googlesource.com/c/go/+/677755 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <mark@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2025-06-02cmd/compile/internal/noder: stub type section and adjust othersMark Freeman
The type definition and object definition sections have nearly the same structure - help illustrate that through consistent naming. Change-Id: Ibed374fca4883a293a7fc16b36034e1acb38362a Reviewed-on: https://go-review.googlesource.com/c/go/+/677378 Auto-Submit: Mark Freeman <mark@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-06-02cmd/compile/internal/noder: begin filling in SectionObjMark Freeman
SectionObj has to encode the definition information for each object type, so it will be a bit long. Change-Id: I9b9514d58a284a4e64020f99fd1b2a92f7752338 Reviewed-on: https://go-review.googlesource.com/c/go/+/677377 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <mark@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-06-02cmd/compile/internal/noder: fill in SectionNameMark Freeman
Change-Id: Ib99d40a546cb095c1b6c2d33e0735f3b5c681539 Reviewed-on: https://go-review.googlesource.com/c/go/+/677237 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <mark@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-29cmd/compile/internal/noder: rename RelIndex to match codebaseMark Freeman
Change-Id: I06b64ea3c1c02b46e242852f8f0b56d77df42161 Reviewed-on: https://go-review.googlesource.com/c/go/+/677236 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <mark@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2025-05-22cmd/compile: do not shapify when reading reshaping exprCuong Manh Le
Fixes #71184 Change-Id: I22e7ae5203311e86a90502bfe155b0597007887d Reviewed-on: https://go-review.googlesource.com/c/go/+/641955 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> 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> Reviewed-by: David Chase <drchase@google.com>
2025-05-22cmd/compile: fix ICE with recursive alias type parameterCuong Manh Le
CL 585399 fixed an initialization loop during IR contruction that involving alias type, by avoiding publishing alias declarations until the RHS type expression has been constructed. There's an assertion to ensure that the alias's type must be the same during the initialization. However, that assertion is too strict, since we may construct different instances of the same type, if the type is an instantination of generic type. To fix this, we could use types.IdenticalStrict to ensure that these types matching exactly. Updates #66873. Updates #73309. Change-Id: I2559bed37e21615854333fb1057d7349406e6a1b Reviewed-on: https://go-review.googlesource.com/c/go/+/668175 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 07:27:15 +0000