ir.ClosureExpr implements ir.InitNode, so ir.InitExpr can prepend init
statements to it. However, CalleeEffects wasn't aware of this and
could cause the init statements to get dropped when inlining a call to
a closure.
This isn't an issue today, because we don't create closures with init
statements. But I ran into this within unified IR.
Easy and robust solution: just take advantage that ir.TakeInit can
handle any node.
Fixes#54918.
Change-Id: Ica05fbf6a8c5be4b11927daf84491a1140da5431
Reviewed-on: https://go-review.googlesource.com/c/go/+/422196
Reviewed-by: Than McIntosh <thanm@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>
Reviewed-on: https://go-review.googlesource.com/c/go/+/429897
Reviewed-by: Michael Knyszek <mknyszek@google.com>
If value is a non-empty interface and has shape, we still need to
convert it to an interface{} first.
Fixes#53587
Change-Id: I516063ba4429a6cc24c483758387ec13815fc63e
Reviewed-on: https://go-review.googlesource.com/c/go/+/414834
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/414835
For type assertions, if either src or dst type has shape, we must
convert them to dynamic type assertions.
Fixes#53357
Change-Id: Ia3362fa67c011febcbdb5b26f856d081b5c366de
Reviewed-on: https://go-review.googlesource.com/c/go/+/411617
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/411934
Reviewed-by: Keith Randall <khr@google.com>
This CL is a manual backport of CLs 403837 and 404914 to Go 1.18.
CL 403837 was intended just as a simplification CL, but evidently it
also fixed#51840. However, for backporting to Go 1.18, the existing
logic needs to be preserved to support -G=0 mode (which still relies
on Ntype).
Fixes#51849.
Change-Id: Ib060b0bc67ecf26de8a65d5b4d2f8a65cd547517
Reviewed-on: https://go-review.googlesource.com/c/go/+/405436
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Noder pass will build a closure to implement generic function
instantiation which may produce `.dict` and `.rcvr` ident.
Since we allow `.dict` during exporting, we should allow `.rcvr` too.
Fixes#52242.
Change-Id: Ifc3912ba5155b5ac1887f20830da64f4fb3fceb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/404314
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit ac39dbdf58e50a2575b891675e7d2e1400b20cfe)
Reviewed-on: https://go-review.googlesource.com/c/go/+/404774
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
When we convert a type to a shaped interface type, we are not able
to recognize the itab. So passing the itab by dictionary as the
workaround.
Fixes#52691.
Change-Id: I75c23c7dd215daf9761dc24116a8af2c28c6d948
Reviewed-on: https://go-review.googlesource.com/c/go/+/401034
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/403934
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
First law of cmd/compile frontend development: thou shalt not rely on
types.Sym.
This CL replaces Type.OrigSym with Type.OrigType, which semantically
matches what all of the uses within the frontend actually care about,
and avoids using types.Sym, which invariably leads to mistakes because
symbol scoping in the frontend doesn't work how anyone intuitively
expects it to.
Fixes#51855.
Change-Id: I4affe6ee0718103ce5006ab68aa7e1bb0cac6881
Reviewed-on: https://go-review.googlesource.com/c/go/+/394274
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit adae6ec542c3287ffe643093a0f61c9871f4e238)
Reviewed-on: https://go-review.googlesource.com/c/go/+/394296
The importer type param index used package name as type parameter key,
causing type parameters to be reused/overwritten if two packages in the
import graph had the same combination of (package name, declaration
name, type parameter name).
Fix this by instead using the *Package in the key.
Note: -G=3 was added to typeparam/issue51836.go, as it is necessary for
1.18 but not for tip.
For #51836Fixes#51847
Change-Id: I881ceaf3cf7c1ab4e0835962350feb552e79b233
Reviewed-on: https://go-review.googlesource.com/c/go/+/394219
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
(cherry picked from commit fd1b5904ae7cc76eefd94d315f92265da5b81b14)
Reviewed-on: https://go-review.googlesource.com/c/go/+/394854
They should not share a shape with regular pointers. We could coalesce
multiple pointer-to-not-in-heap types, but doesn't seem worth it - just
make them fully stenciled.
Fixes#51741
Change-Id: Ie8158177226fbc46a798e71c51897a82f15153df
Reviewed-on: https://go-review.googlesource.com/c/go/+/393895
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit fcf6afb82dc1e9f80a6260467026adc11d5c9529)
Reviewed-on: https://go-review.googlesource.com/c/go/+/393935
CL 338129 added getDictionaryType to get the dictionary type from the
specified dict param, but still using the one in info.dictParam, which
is wrong.
Fixes#51669
Change-Id: Ie13460c1e5751c4c5fc44479a44f6eed8b3b06e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/391994
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/392614
For hidden closure built during stenciling to implement a function
instantiation, the function may come from other package, not local
package, which causes the ICE for code that re-export the hidden closure
after inlining.
To fix it, use the closure package for export writer when writing out
the closure itself.
Fixes#51423
Change-Id: I23b067ba14e2d602a0fc3b2e99bd9317afbe53ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/391574
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 9743e9b6d8e150639f509fc64e4bc5f24ecce562)
Reviewed-on: https://go-review.googlesource.com/c/go/+/391774
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Both the thing we're switching on, as well as the cases we're switching for.
Convert anything containing a type parameter to interface{} before the
comparison happens.
Fixes#51522
Change-Id: I97ba9429ed332cb7d4240cb60f46d42226dcfa5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/391594
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit 2e46a0a99768408c90cf4eeda3690831693fd8b2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/391795
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
At this point in stenciling, we have shape types, not raw type parameters.
The code was correct in the other part of this function.
Update #51522
Change-Id: Ife495160a2be5f6af5400363c3efb68dda518b5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/391475
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: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 8cf11694abbfbdbd4fe0b2c08511f81b8bfe5017)
Reviewed-on: https://go-review.googlesource.com/c/go/+/391794
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is a feature that is not understood well enough and may have
subtle repercussions impacting future changes. Disable for Go 1.18.
The actual change is trivial: disable a branch through a flag.
The remaining changes are adjustments to tests.
Fixes#51576.
Change-Id: Ib77b038b846711a808315a8889b3904e72367bce
Reviewed-on: https://go-review.googlesource.com/c/go/+/391135
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit b8248fab897da9bee2211a98df1656883ccecd6d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/391355
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Inference for type instances has dependencies on type-checking order
that can lead to subtle bugs. As explained in #51527, disable it for
1.18.
Fixes#51527
Change-Id: I42795bad30ce53abecfc5a4914599ae5a2041a9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/387934
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 28fab5ef21d8aef72634f9c251fbeb4039dababa)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390576
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL is a bit overkill, but it is pretty safe for 1.18. We'll
want to revisit for 1.19 so we can avoid the hash collisions between
types, e.g. G[int] and G[float64], that will cause some slowdowns
(but not incorrect behavior). Thanks Cherry for the simple idea.
Fixes#51250
Change-Id: I68130e09ba68e7cc35687bc623f63547bc552867
Reviewed-on: https://go-review.googlesource.com/c/go/+/389474
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit d3672054fb58d5eaa241f15fa9d7fb9d61e9ac05)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390017
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
When doing constraint type inference, we must consider whether the
constraint's core type is precise (no tilde) or imprecise (tilde,
or not a single specific type). In the latter case, we cannot infer
an unknown type argument from the (imprecise) core type because there
are infinitely many possible types. For instance, given
[E ~byte]
if we don't know E, we cannot infer that E must be byte (it could be
myByte, etc.). On the other hand, if we do know the type argument,
say for S in this example:
[S ~[]E, E any]
we must consider the underlying type of S when matching against ~[]E
because we have a tilde.
Because constraint type inference may infer type arguments that were
not eligible initially (because they were unknown and the core type
is imprecise), we must iterate the process until nothing changes any-
more. For instance, given
[S ~[]E, M ~map[string]S, E any]
where we initially only know the type argument for M, we must ignore
S (and E) at first. After one iteration of constraint type inference,
S is known at which point we can infer E as well.
The change is large-ish but the actual functional changes are small:
- There's a new method "unknowns" to determine the number of as of yet
unknown type arguments.
- The adjCoreType function has been adjusted to also return tilde
and single-type information. This is now conveniently returned
as (*term, bool), and the function has been renamed to coreTerm.
- The original constraint type inference loop has been adjusted to
consider tilde information.
- This adjusted original constraint type inference loop has been
nested in another loop for iteration, together with some minimal
logic to control termination.
The remaining changes are modifications to tests:
- There's a substantial new test for this issue.
- Several existing test cases were adjusted to accomodate the
fact that they inferred incorrect types: tildes have been
removed throughout. Most of these tests are for pathological
cases.
- A couple of tests were adjusted where there was a difference
between the go/types and types2 version.
Fixes#51229.
Change-Id: If0bf5fb70ec22913b5a2da89adbf8a27fbc921d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/387977
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 0807986fe6bf6040bafa9c415ab72e4cc8e519a4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390015
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We convert type args to shape types inside instantiations. If an
instantiation constructs a compound type based on that shape type and
uses that as a type arg to another generic function being called, then
we have a type arg with a shape type embedded inside of it. In that
case, we need to substitute out those embedded shape types with their
underlying type.
If we don't do this, we may create extra unneeded shape types that
have these other shape types embedded in them. This may lead to
generating extra shape instantiations, and a mismatch between the
instantiations that we used in generating dictionaries and the
instantations that are actually called.
Updates #51303
Change-Id: Ieef894a5fac176cfd1415f95926086277ad09759
Reviewed-on: https://go-review.googlesource.com/c/go/+/387674
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In getInstantiation, we were not computing tparams correctly for the
case where the receiver of a method was a fully-instantiated type. This
wasn't affecting later parts of the function, since method
instantiations of fully-instantiated types were already being calculated
in an earlier path. But it did give us a non-typeparam when trying to
see if a shape was associated with a type param with a structural type.
The fix is just to get the typeparams associated with the base generic
type. Then we can eliminate a conditional check later in the code.
The tparam parameter of Shapify should always be non-nil
Fixes#51367
Change-Id: I6f95fe603886148b2dad0c581416c51373c85009
Reviewed-on: https://go-review.googlesource.com/c/go/+/388116
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Normally types of constants are emitted when the type is defined (an
ODCLTYPE). However, the types of constants where the type is an
instantiated generic type made inside the constant declaration, do not
normally get emitted. But the DWARF processor in the linker wants
to see those types. So we emit them during stenciling.
Fixes#51245
Change-Id: I59f20f1d7b91501c9ac760cf839a354356331fc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388117
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The existing test for 51219 didn't actually trigger the types2 issue - I
hadn't been able to minimize the test case yet properly. This new test
case issue51219b.go now does trigger the types2 issue (it's only
slightly different).
Updates #51219
Change-Id: Iaba8144b4702ff4fefec86c899b8acef127b10dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/387814
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The problem in 51355 is that escape analysis decided that the
dictionary variable was captured by reference instead of by value. We
want dictionaries to always be captured by value.
Escape analysis was confused because it saw what it thought was a
reassignment of the dictionary variable. In fact, it was the only
assignment, it just wasn't marked as the defining assignment. Fix
that.
Add an assert to make sure this stays true.
Fixes#51355
Change-Id: Ifd9342455fa107b113f5ff521a94cdbf1b8a7733
Reviewed-on: https://go-review.googlesource.com/c/go/+/388115
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Delay validation of receiver type as it may cause premature expansion
of types the receiver type is dependent on. This was actually a TODO.
While the diff looks large-ish, the actual change is small: all the
receiver validation code has been moved inside the delayed function
body, and a couple of comments have been adjusted.
Fixes#51232.
Fixes#51233.
Change-Id: I44edf0ba615996266791724b832d81b9ccb8b435
Reviewed-on: https://go-review.googlesource.com/c/go/+/387918
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We changed to delaying all transforms of generic functions, since there
are so many complicated situations where type params can be used. We
missed changing so that all Call expressions(not just some) are delayed
if in a generic function. This changes to delaying all transforms on
calls in generic functions. Had to convert Call() to g.callExpr() (so we
can access g.delayTransform()). By always delaying transforms on calls
in generic functions, we actually simplify the code a bit both in
g.CallExpr() and stencil.go.
Fixes#51236
Change-Id: I0342c7995254082c4baf709b0b92a06ec14425e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/386220
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The code for issue #51219 reveals bugs in the types1 and types2
importers that can occur for recursive types that are recursive through
the type constraint.
The crash in the issue is caused by the types1 bug, which leads to the
production of a type1 type which is incomplete and improperly has the
HasTParam flag set. The bug in the types1 importer is that we were not
deferring type instantiations when reading the type parameters, but we
need to do that exactly to correctly handle recursion through the type
constraint. So, the fix is to move the start of the deferrals (in the
'U' section of doDecl in typecheck/iimport.go) above the code that reads
the type params.
Once that bug is fixed, the test still crashes due to a related types2
importer issues. The problem is that t.SetConstraint(c) requires c to be
fully constructed (have its underlying type set). Since that may not be
done yet in the 'U' case in (*importReader).obj() in
importer/iimport.go, we need to defer the call to SetConstraint() in
that case, until we are done importing all the types.
I added a test case with recursion through a type constraint that causes
a problem that is fixed by the types1 importer change, though the error
is not the same as in the issue. I added more types in the test case
(which try to imitate the issue types more closely) the types2 bug, but
wasn't able to cause it yet with the smaller test case.
Fixes#51219
Change-Id: I85d860c98c09dddc37f76ce87a78a6015ec6fd20
Reviewed-on: https://go-review.googlesource.com/c/go/+/386335
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a pure rename of the respective Go functions/methods
with corresponding adjustments to error messages and tests.
A couple of comments were manually rephrased.
With this change, the implementation and error messages match
the latest spec.
No functionality change.
Change-Id: Iaa92a08b64756356fb2c5abdaca5c943c9105c96
Reviewed-on: https://go-review.googlesource.com/c/go/+/384618
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
It has moved to golang.org/x/exp/constraints. Perhaps it will move
back to the standard library in a future release.
For golang/go#45458Fixesgolang/go#50792
Change-Id: I93aa251a7afe7b329a3d3faadc0c5d6388b1f0e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/382460
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
We can type-check these fine but the API implications are unclear.
Fixes#50912.
For #50937.
Change-Id: If29bbb4a257ff6a85e3bfcd4755fd8f90c80fb87
Reviewed-on: https://go-review.googlesource.com/c/go/+/382116
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
- Use the correct predicate in Checker.implements: for interfaces
we cannot use the API Comparable because it always returns true
for all non-type parameter interface types: Comparable simply
answers if == and != is permitted, and it's always been permitted
for interfaces. Instead we must use Interface.IsComparable which
looks at the type set of an interface.
- When comparing interfaces for identity, we must also consider the
whether the type sets have the comparable bit set.
With this change, `any` doesn't implement `comparable` anymore. This
only matters for generic functions and types, and the API functions.
It does mean that for now (until we allow type-constrained interfaces
for general non-constraint use, at some point in the future) a type
parameter that needs to be comparable cannot be instantiated with an
interface anymore.
For #50646.
Change-Id: I7e7f711bdcf94461f330c90509211ec0c2cf3633
Reviewed-on: https://go-review.googlesource.com/c/go/+/381254
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For a composite literal expression like []T{{f: 1}}, we allow T to be
a pointer to struct type, so it's consistent to allow T to also be a
type parameter whose structural type is a pointer to struct type.
Fixes#50833.
Change-Id: Ib0781ec4a4f327c875ea25b97740ff2c0c86b916
Reviewed-on: https://go-review.googlesource.com/c/go/+/381075
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add a missing shape check in (*Tsubster).tinter when substituting on a
generic type which is an empty interface, analogous to same check in
(*Tsubster).tstruct. Empty structs/interfaces that have rparams (i.e.
are a generic type or a shape type) need to get a new type of their
rparams - they will be different even though they don't have any
fields/methods. Without this shape check, we were not correctly
completing the Token[int] type during substitution in the example in the
issue. This issue only happens for a generic type which is an empty
interface (i.e. doesn't actually use the type param, hence quite unusual).
Added the test case already created by Keith.
Fixes#50841
Change-Id: Ia985b9f52c0e87ed0647b46373e44c51cb748ba4
Reviewed-on: https://go-review.googlesource.com/c/go/+/381175
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
For #50646.
Change-Id: I7420545556e0df2659836364a62ce2c32ad7a8b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/380654
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We have disallowed having a typeparam on the right-hand-side of a type
declaration. So, we disabled much of the test absdiff.go. I recently
wrote a new test absdiff2.go to use a structure containing the type
param type, so I could attach a method properly and run the full test.
As a contrast, I thought I would create absdiff3.go, where the Abs
functionality is passed in as a function callback (but derived from a
generic function). This is simpler, and more inline with some of the
guidelines that Ian has been proposing (use passed-in functions rather
than requiring methods, when possible, for greater ease-of-use).
Only adds a new test absdiff3.go. (And fixes a comment in absdiff2.go.)
Change-Id: I6dd185b50a3baeec31f689a892319963468a7201
Reviewed-on: https://go-review.googlesource.com/c/go/+/380774
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Added a new absdiff2.go test case, which works fully without using a
typeparam on the right-hand-side of a type declaration (which is
disallowed). Fixed an issue that the test revealed, which is that we
need to set g.curDecl properly for the "later" functions which are
deferred until after all declarations are initially processed. Also,
g.curDecl may be non-nil in typeDecl for local type declaration. So, we
adjust the associate assertion, and save/restore g.curDecl
appropriately.
Fixes#50790
Change-Id: Ieed76a7ad0a83bccb99cbad4bf98a7bfafbcbbd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/380594
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
By processing non-alias type declarations before alias type declaration,
and those before everything else we can avoid some of the remaining
errors which are due to alias types not being available.
For #25838.
For #50259.
For #50276.
For #50729.
Change-Id: I233da2899a6d4954c239638624dfa8c08662e6b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/380056
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The type checker doesn't have a general mechanism to "use" the type
of a type alias whose type depends on a recursive type declaration
which is not yet completely type-checked. In some cases, the type of
a type alias is needed before it is determined; the type is incorrect
(invalid) in that case but no error is reported. The type-checker is
happy with this (incorrect type), but the compiler may crash under
some circumstances.
A correct fix will likely require some form of forwarding type which
is a fairly pervasive change and may also affect the type checker API.
This CL introduces a simple side table, a map of broken type aliases,
which is consulted before the type associated with a type alias is
used. If the type alias is broken, an error is reported.
This is a stop-gap solution that prevents the compiler from crashing.
The reported error refers to the corresponding issue which suggests
a work-around that may be applicable in some cases.
Also fix a minor error related to type cycles: If we have a cycle
that doesn't start with a type, don't use a compiler error message
that explicitly mentions "type".
Fixes#50259.
Fixes#50276.
Fixes#50779.
For #50729.
Change-Id: Ie8e38f49ef724e742e8e78625e6d4f3d4014a52c
Reviewed-on: https://go-review.googlesource.com/c/go/+/379916
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In validType, when we see an instantiated type, proceed as with
non-generic types but provide an environment in which to look up
the values (the corresponding type arguments) of type parameters
of the instantiated type. For each type parameter for which there
is a type argument, proceed with validating that type argument.
This corresponds to applying validType to the instantiated type
without actually instantiating the type (and running into infinite
instantiations in case of invalid recursive types).
Also, when creating a type instance, use the correct source position
for the instance (the start of the qualified identifier if we have an
imported type).
Fixes#48962.
Change-Id: I196c78bf066e4a56284d53368b2eb71bd8d8a780
Reviewed-on: https://go-review.googlesource.com/c/go/+/379414
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Given we have support for field access to type params with a single
structural type, we need to distinguish between methods calls and field
access when we have an OXDOT node on an expression which is a typeparam
(or correspondingly a shape). We were missing checks in getInstInfo,
which figures out the dictionary format, which then caused problems when
we generate the dictionaries. We don't need/want dictionary entries for
field access, only for bound method calls. Added a new function
isBoundMethod() to distinguish OXDOT nodes which are bound calls vs.
field accesses on a shape.
Removed isShapeDeref() - we can't have field access or method call on a
pointer to variable of type param type.
Fixes#50690
Change-Id: Id692f65e6f427f28cd2cfe474dd30e53c71877a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/379674
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
In a method declaration "func (f *Foo[_, _]) String() string { ... }",
the two blank typeparams have the same name, but our current design with
types1 needs unique names for type params. Similarly, for export/import,
we need unique names to keep the type params straight in generic types
and connect the proper type param with the proper constraint. We make
blank type params unique by changing them to $1, $2, etc in noder.typ0()
via typecheck.TparamExportName(). We then revert $<num> back to _ during
type2 import via typecheck.TparamName(). We similarly revert
during gcimporter import. We don't need/want to revert in the types1
importer, since we want unique names for type params.
Rob Findley has made a similar change to x/tools (and we tried to make
the source code changes similar for the gcimporter and types2 importer
changes).
Fixes#50419
Change-Id: I855cc3d90d06bcf59541ed0c879e9a0e4ede45bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/379194
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Most CONVIFACEs are created in the transform phase (or old typechecker,
in -G=0 mode). But if the main result of a multi-value assignment (map,
channel, or dot-type) must be converted to an interface during the
assignment, that CONVIFACE is not created until (*orderState).as2ok in
the order phase (because the AS2* ops and their sub-ops are so tightly
intertwined). But we need to create the CONVIFACE during the
stenciling/transform phase to enable dictionary lookups. So, in
transformAssign(), if we are doing a special multi-value assignment
involving a type-param-derived type, assign the results first to temps,
so that we can manifest the CONVIFACE during the transform in assigning
the first temp to lhs[0].
Added a test for both AS2RECV (channel receives) and AS2MAPR (maps). I
don't think we can have a type assertion on a type-param-derived type.
Fixes#50642
Change-Id: I4d079fc46c93d8494d7db4ea8234d91522edb02a
Reviewed-on: https://go-review.googlesource.com/c/go/+/379054
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the compiler, we need to distinguish field and method access on a
type param. For field access, we avoid the dictionary access (to create
an interface bound) and just do the normal transformDot() (which will
create the field access on the shape type).
This field access works fine for non-pointer types, since the shape type
preserves the underlying type of all types in the shape. But we
generally merge all pointer types into a single shape, which means the
field will not be accessible via the shape type. So, we need to change
Shapify() so that a type which is a pointer type is mapped to its
underlying type, rather than being merged with other pointers.
Because we don't want to change the export format at this point in the
release, we need to compute StructuralType() directly in types1, rather
than relying on types2. That implementation is in types/type.go, along
with the helper specificTypes().
I enabled the compiler-related tests in issue50417.go, added an extra
test for unnamed pointer types, and added a bunch more tests for
interesting cases involving StructuralType(). I added a test
issue50417b.go similar to the original example, but also tests access to
an embedded field.
I also added a unit test in
cmd/compile/internal/types/structuraltype_test.go that tests a bunch of
unusual cases directly (some of which have no structural type).
Updates #50417
Change-Id: I77c55cbad98a2b95efbd4a02a026c07dfbb46caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/376194
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When we export a shape instantiation, because a particular
fully-instantiated type is needed by an inlineable function, we possibly
export the body of the instantiation, if it is inlineable. In this case,
we should have been calling ImportedBody() to make sure that the
function body had already been read in (if it is actually imported from
another package).
Fixes#50598
Change-Id: I512d2bcc745faa6ff3a97e25bc8f46e2c2643d23
Reviewed-on: https://go-review.googlesource.com/c/go/+/378494
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
In order to make sure we export the dictionaries/shape methods for all
fully-instantiated types in inlineable functions, we need to descend
fully into types. For example, we may have a map type (e.g.
map[transactionID]Promise[*ByteBuffer]), where the key or value is a new
fully-instantiated type. So, I add a new checkFullyInst() traversal
function, which traverses all encountered types, but maintains a map, so
it only traverse it type once. We need to descend fully into interfaces,
structs, and methods, since a fully-instantiated type make occur in any
fields or arguments/results of methods, etc.
Fixes#50561
Change-Id: I88681a30384168539ed7229eed709f4e73ff0666
Reviewed-on: https://go-review.googlesource.com/c/go/+/378154
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
