Add a simple test with an exported generic function that does
recover/defer, to test that recover/defer are exported/imported
properly (and a generic function with recover/defer works fine).
Change-Id: Idc3af101cbb78fc96bf945f1f5eab2740dd8994b
Reviewed-on: https://go-review.googlesource.com/c/go/+/353883
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>
Change-Id: Icabef5cf75770ffde012b1fc785a72f53f9b2c46
Reviewed-on: https://go-review.googlesource.com/c/go/+/353669
Trust: Robert Griesemer <gri@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
This change enables the relaxed syntax for constraint literals
as proposed in issue #48424 and adds a simple smoke test for
the compiler. (Most of the relevant changes are in the syntax
and types2 package which have more extensive tests for this.)
This makes it possible to experiment with the new syntax while
we contemplate the fate of #48424.
If #48424 is accepted, this change can remain. If #48424 is
not accepted, reverting this CL will remove this feature in
the compiler.
For #48424.
Change-Id: I624fbb37c2f616ee9ad692e17e4fc75c9d5b06e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353389
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
When collecting type parameters, wrap constraint literals of the
form ~T or A|B into interfaces so the type checker doesn't have
to deal with these type set expressions syntactically anywhere
else but in interfaces (i.e., union types continue to appear
only as embedded elements in interfaces).
Since a type constraint doesn't need to be an interface anymore,
we can remove the respective restriction. Instead, when accessing
the constraint interface via TypeParam.iface, wrap non-interface
constraints at that point and update the constraint so it happens
only once. By computing the types sets of all type parameters at
before the end of type-checking, we ensure that type constraints
are in their final form when accessed through the API.
For #48424.
Change-Id: I3a47a644ad4ab20f91d93ee39fcf3214bb5a81f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/353139
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The computation for determining the shapes to use at the top of
getInstantation was not always creating shapes with the proper indexes.
If an instantiation is being called from another instantiated function,
we cannot just copy the shape types unchanged, because their indexes may
have changed. So, for type args that already shapes, we still call
Shapify() with the correct index.
Fixes#48645
Change-Id: Ibb61c6f9a3c317220fb85135ca87eb5ad4dcff9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/353030
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>
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>
In CL 349613,we have supported types.IdentityStrict() that does strict
type comparison.
Therefore, OCONVNOP becomes a possible case in call.X.Op().
Fixes#48604
Change-Id: Ibab27ffcf09656e3380314662f05f38294c1c6ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/351857
Trust: Dan Scales <danscales@google.com>
Trust: David Chase <drchase@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
For #48617
Change-Id: I6c00b7912c441ac323a0adede63b7d4a9ae6f92d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351858
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
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>
In CL 349614. we removed the early transformation code that
was needed to create the implicit CONVIFACE nodes.
Because the transformCall function is not called when translating OFUNCINST.
So we add in needed CONVIFACE nodes via typecheckaste().
Fixes#48598
Change-Id: If9dc7040cdc38ef2e52fdbb08c840095651426f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/351856
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
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>
Deal correctly with a blank local variable with type param type. This is
a special case, because a blank local variable is not in the fn.Dcl
list. In this case, we must explicitly create a new blank node with the
correct substituted type, so we have correct types if the blank local
variable has an initializing assignment.
Fixes#48602
Change-Id: I903ea44b29934e180404e32800773b7309bf297b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352117
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
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>
In markType() in crawler.go, mark the type of a unexported field if it
is a fully-instantiated type, since we create and instantiate the
methods of any fully-instantiated type that we see during import. As
before, we still do not mark the type of an unexported field if that
type is not generic. Fixes#48454 and most recent issue described in
48337. The included test is similar to the case in 48454.
Fixes#48454Fixes#48337
Change-Id: I77a2a62b9e2647876facfa6f004201e8f699c905
Reviewed-on: https://go-review.googlesource.com/c/go/+/351315
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Adjust types2 and go/types and some test cases.
Because `any` is not treated specially anymore in constraint
position we get additional errors in constraints if `any` is
used before Go1.18 (in addition to the error that type parameter
lists are not permitted before Go1.18).
Fixes#33232.
Change-Id: I85590c6094b07c3e494fef319e3a38d0217cf6f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/351456
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
xml names can't have any of '[],' in them, which might appear in
generic type names. Truncate at the first '[' so the names are still valid.
Fixes#48318
Change-Id: I110ff4269f763089467e7cf84b0f0c5075fb44b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/349349
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When going to dictionary formats derived from the function
instantiations, I had broken out noder.Assignop() to deal specially with
shape types, but didn't quite get the tricky case right. We still need
to allow conversion between shape types, but if the destination is an
interface, we need to use CONVIFACE rather than CONVNOP.
Fixes#48453.
Change-Id: I8c4b39c2e628172ac34f493f1dd682cbac1e55ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/350949
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
As with other recent issues, the Init field of a range loop was not
being handled properly. Generally, it is much better to explicitly
import/export the Init statements, else they are incorrectly added
before the associated node, rather than as the Init value of the node.
This was causing labels to not be correctly added to the range loop that
it is immediately preceding.
Made the ORANGE handling completely similar to the OFOR handling.
Fixes#48462
Change-Id: I999530e84f9357f81deaa3dda50660061f710e7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350911
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
This also requires that we sometimes delay transformSelect(), if the
assignments in the Comm part of the select have not been transformed.
Fixes#48137
Change-Id: I163aa1f999d1e63616280dca807561b12b2aa779
Reviewed-on: https://go-review.googlesource.com/c/go/+/347915
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>
There are a bunch of nodes beside ONAME and OTYPE, (such as OSTRUCTLIT
and OCOMPLIT) which can introduce a generic type that we need to mark.
So, just mark any generic type on any node in markInlBody. In this
particular issue, the type is introduced by an OSTRUCTLIT node.
Updates #48337
Change-Id: I271932518f0c1fb54d91a603e01a855c69df631d
Reviewed-on: https://go-review.googlesource.com/c/go/+/349909
Trust: Dan Scales <danscales@google.com>
Trust: Carlos Amedee <carlos@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Move ShapePkg to types, and change types.NewNamed to automatically set
IsShape/HasShape if a type is in the shapes pkg. This means that
imported shape types will automatically have the correct
IsShape/HasShape flags, even though we are not explicitly
exporting/importing those flags.
Updates #48337
Change-Id: I8b6131a663205f73f395943c9d0c8bdb2a213401
Reviewed-on: https://go-review.googlesource.com/c/go/+/349869
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>
This is a port of CL 349009 to typecheck importer.
Fixes#48306
Change-Id: Iec3f078089346bd85f0ab739896e079940325011
Reviewed-on: https://go-review.googlesource.com/c/go/+/349011
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>
The importReader always reads type parameter before declaring type stub
declaration. Thus, for recursive type, the type parameter is going to be
read twice, cause the bound more than once error.
To fix this, only read the type parameter after declaring stub obj, thus
r.doDecl can see the type was already inserted and terminate the
recursive call earlier.
Fixes#48280
Change-Id: I272e2f214f739fb8ec71a8628ba297477e1b7755
Reviewed-on: https://go-review.googlesource.com/c/go/+/349009
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>
Fixes#48317
Change-Id: I756ae6253022870071004332dd8f49169307f7e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/349013
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
If closure in a global assignment and has a method receiver.
We should assign receiver as a global variable, not a local variable.
Fixes#48225
Change-Id: I8f65dd6e8baf66a5eff24028d28ad0a594091add
Reviewed-on: https://go-review.googlesource.com/c/go/+/348512
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
gri@ reports that types2 now correctly handles when type parameters
recursively refer back to the parameterized type, so we might as well
add tests to exercise that. Unified IR also correctly handles
importing and exporting these types, but -G=3 currently does not.
Updates #46461.
Change-Id: I272102aa08c40c980b9aeeca9f834291dfbbcc3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/348738
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>
A generic conversion might be required for when converting T->interface{}.
When stenciled with T=interface{}, then that conversion doesn't need
to do anything.
Fixes#48276
Change-Id: Ife65d01c99fbd0895cb7eec79df9e93e752b1fa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/348736
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
CL 347529 broke the longtest builders due to missing -G=3 flag when
compiling the added test.
Change-Id: I73007801dd6871a8cf3554e957d247f5f56fd641
Reviewed-on: https://go-review.googlesource.com/c/go/+/348330
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
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>
In case of embedded field, if the receiver was fully instantiated, we
must use its instantiated type, instead of passing the type params of
the base receiver.
Fixes#47797Fixes#48253
Change-Id: I97613e7e669a72605137e82406f7bf5fbb629378
Reviewed-on: https://go-review.googlesource.com/c/go/+/348549
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Added new function earlyTransformAssign() to add needed CONVIFACE nodes
due to assignments in generic functions.
Fixes#48049
Change-Id: I7cd9cee6ecf34ed2ef0743d1b17645b9f520fa00
Reviewed-on: https://go-review.googlesource.com/c/go/+/347914
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>
We had code in NewPtr() to set the HasTParam/HasShape flag as needed for
the cached ptr element if it wasn't set correctly based on its Elem.
This was causing the race mentioned in the issue.
But that setting code is no longer needed, as long as we call
SetRParams() soon after calling NewIncompleteNamedType(), before
creating/translating the underlying type (which we do). The
HasTParam/HasShape attribute can only come from setting of rparams or a
direct typeparam/shape somewhere in the underlying type, both of which
don't depend on recursion, etc. (as long as the rparams are set early).
Added a check that HasTParam/HasShape are set correctly for the cached
pointer/slice elems in NewPtr() and NewSlice().
Fixes#48191
Change-Id: Ide7d82efb77ae97901e75b2e6c65bd1bfc25e0ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/348089
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>
We should be putting a newly instantiated imported type in
Instantiate/doInst onto the instTypeList, so its methods/dictionaries
are instantiated. To do this, we needed a more general way to add a
type to instTypeList, so add NeedInstType(), analogous to
NeedRuntimeType(). This has the extra advantage that now all types
created by the type substituter are added to instTypeList without any
extra code, which was easy to forget. doInst() now correctly calls
NeedInstType().
This is a bit aggressive, since a fully instantiated type in a generic
function/method may never be used, if the generic method is never
instantiated in the local package. But it should be fairly uncommon for
a generic method to mention a fully instantiated type (but it does
happen in this bug).
Fixes both cases mentioned in the bug.
Fixed#48185
Change-Id: I19b5012dfac17e306c8005f8595a648b0ab280d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/347909
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
For lazy import resolution, there's reentrancy issue with (*Named).load
method, when "t.resolve(t)" can lead us to the same named type, thus
(*Named).load is called recursively, causing the deadlock.
The main problem is that when instantinate a type, we calculate the type
hashing, including TParams. Calling t.TParams().Len() triggers the
reentrancy call to "(*Named).load".
To fix this, just not checking TParams().Len() if we are hashing.
Updates #48185
Change-Id: Ie34842d7b10fad5d11fbcf75bb1c64a89deac6b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/347534
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Now we have two functions that create names for instantiated types.
They are inconsistent when dealing with byte/rune type.
This CL makes instTypeName2 reuse the code of typecheck.InstTypeName
Fixes#48198
Change-Id: I4c216b532cba6618ef9b63fd0b76e8f1c0ed7a75
Reviewed-on: https://go-review.googlesource.com/c/go/+/347491
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Add (temporary) syntax.AllowTypeLists mode to control the
acceptance of type lists; the compiler doesn't set it,
but existing syntax and types2 tests do so that the code
remains exercised while it exists.
Adjust various tests to use the type set notation.
Change-Id: I798e607912552db6bfe38a7cd4324b74c6bf4d95
Reviewed-on: https://go-review.googlesource.com/c/go/+/347249
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
If the TypeParam has all the methods of an interface, allow conversions from TypeParam to interface
Fixes#47708
Change-Id: I40a82a31f6ea9354130dbe3bcfc83537094bf12c
Reviewed-on: https://go-review.googlesource.com/c/go/+/342509
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Missing case types.TUNSAFEPTR in parameterizedBy().
Also realized there was the same missing case in the type substituter
(*Tsubster).Typ().
Fixes#48103
Change-Id: If71f1a6ef80932f0e2120d4c18b39a30189fd8fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/346669
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
When the Defn field of a name node is not an ONAME (for a closure
variable), then it points to a body node of the same function/closure.
Therefore, we should not attempt to substitute it at the time we are
substituting the local variables. Instead, we remember a mapping from the
Defn node to the nodes that reference it, and update the Defn fields of
the copied name nodes at the time that we create the new copy of the
Defn node.
Added some comments to the Defn field of ir.Name.
Moved the Defn (and Outer code, for consistency) from namelist() to
localvar(), since Defn needs to updated for all local variables, not
just those in a closure. Fixed case where .Defn was not being set
properly in noder2 for type switches. Fixed another case where the Defn
field had to be updated during transformSelect() because the Defn node
was being completely changed to a new node.
Fixed some spacing in typeswitch2.go
Fixes#47676Fixes#48016
Change-Id: Iae70dd76575f4a647c1db79e1eba9bbe44bfc226
Reviewed-on: https://go-review.googlesource.com/c/go/+/346290
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>
Now that unsafe.Sizeof and friends can operate on generic parameters,
and evaluate to non-constants, we need to export/import them correctly.
Fixes#48094
Change-Id: If3ebf77255385cd5462e13fb7ced8b157ba3cf5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/346469
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The existing approach (alias name stands for generic type name)
is an exception: it's the only place where a generic type could
be used without explicit instantiation. The correct solution is
currently under discussion (see proposal issue #46477).
This CL requires that the RHS of an alias type declaration be
an instantiated non-generic type. If #46477 is accepted, the
implementation will require proper representation of alias
types.
Change-Id: Ie85b923213a64f39837e56e38e14757458272b93
Reviewed-on: https://go-review.googlesource.com/c/go/+/346294
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We were using the type from the wrong Node (the partially filled-in
FUNCINST) rather than the original function node - which is pointed to
by the OFUNCINST)) to set the final fully-substituted type of the
OFUNCINST. So fixed the node reference. Also, added check so we don't do
any work at all if the OFUNCINST already has all type args filled in.
Added few extra cases to the test file issue48030.go, to cover
fully-specified type args, partially inferred type args, and fully
inferred type args.
Fixes#48030
Change-Id: If9e4f2e0514d68b9d241f30c423259133932b25b
Reviewed-on: https://go-review.googlesource.com/c/go/+/346229
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Fixes#48056
Change-Id: I13ca4caadbabf02084f66ab28b4cf0c4a3705370
Reviewed-on: https://go-review.googlesource.com/c/go/+/346049
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This issue has been fixed in https://golang.org/cl/345411Fixes: #47892
Change-Id: I13dd3814650913da065e5f24a0c61d30adb0633a
Reviewed-on: https://go-review.googlesource.com/c/go/+/345229
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Support 'type C comparable' properly by using the same logic as for
'type T error', since ErrorType and ComparableType are entirely
analogous.
Added support for 'any' type as well, as requested by Robert. (For the
future - we can't currently have 'any' anywhere other than in a
constraint.)
Fixes#47966
Change-Id: I68bd284ced9a8bfca7d2339cd576f3cb909b1b83
Reviewed-on: https://go-review.googlesource.com/c/go/+/345174
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>
Conversions need to allow nil through.
We do that using a CONVIFACE instead of a DOTTYPE.
Also reorganize how nonempty interfaces are handled.
For nonempty to empty, a simple CONVIFACE suffices.
For nonempty to nonempty, we need to call the runtime to get the
new itab. Use the entry from the dictionary to identify the
target interface type (if parameterized).
Fixes#47925
Change-Id: I4ffeed964318bb3e270b06f558e6ab9c5bfc7188
Reviewed-on: https://go-review.googlesource.com/c/go/+/344830
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>
type I[T any] interface{}
This is an interface, but it has a type parameter.
We need to distinguish that from an interface that is not parameterized.
That means when doing type substitution on an interface with
parameters, we need to make a new one.
Same for non-empty interfaces. Even if the type parameter is not
used in any method, we sill need to make a new type.
Similar case to tstruct, above.
Change-Id: I23ad9f21d2c4ef675bf3f7d84899d9e4919d05e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/344578
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>
We need to delay fillinMethods until we get to a top-level type, so we
know all the TFORW types have been filled in, and we can do the
substitutions required by fillinMethods.
Fixes#47710
Change-Id: I298de7e7753ed31a2c2b1ff04f35177a8afc7a66
Reviewed-on: https://go-review.googlesource.com/c/go/+/345149
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This problem happens when you create a new local type that uses an
imported generic type (maybe just by instantiating it), and then that
local type needed to be included as part of an export. In that case, the
imported generic type is does not have a declaration in the local
package, so it is not necessarily created in types1, so the
crawler/export doesn't work.
To fix this issue, we just need to add a call to g.obj() for the base
generic type, to make sure that it will exist if needed later in the
compilation or for the crawler during export.
Fixes#47514
Change-Id: Ie756578f07ad0007de8a88ae909cf7534a22936e
Reviewed-on: https://go-review.googlesource.com/c/go/+/345411
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
