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>
Slightly better for cases such as string(1 << s).
Leaves type-checker tests alone for now because
there are multiple dozens.
For #45117.
Change-Id: I47b314c713fabe424c2158674bf965416a8a6f5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/379274
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For an extension operation like MOWWreg, if the operand is already
extended, we optimize the second extension out. Usually a LoadReg
of a proper type would come already extended, as a MOVW/MOVWU etc.
instruction does. But for a LoadReg to a floating point register,
the instruction does not do the extension. So we cannot elide the
extension.
Fixes#50671.
Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3
Reviewed-on: https://go-review.googlesource.com/c/go/+/379236
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently the code handles the case of returning values from
a function with no result parameters as a special case.
Consider this input:
package p
func f0_2() { return 1, 2 }
func f0_1() { return 1 }
func f1_0() int { return }
func f1_2() int { return 1, 2 }
func f2_0() (int, int) { return }
func f2_1() (int, int) { return 1 }
The errors are:
x.go:3:33: no result values expected <<<
x.go:4:33: no result values expected <<<
x.go:5:26: not enough return values
have ()
want (int)
x.go:6:36: too many return values
have (number, number)
want (int)
x.go:7:26: not enough return values
have ()
want (int, int)
x.go:8:33: not enough return values
have (number)
want (int, int)
There are two problems with the current special case emitting the
errors on the marked line:
1. It calls them 'result values' instead of 'return values'.
2. It doesn't show the type being returned, which can be useful to programmers.
Using the general case solves both these problems,
so this CL removes the special case and calls the general case instead.
Now those two errors read:
x.go:3:33: too many return values
have (number, number)
want ()
x.go:4:33: too many return values
have (number)
want ()
Fixes#50653.
Change-Id: If6b47dcece14ed4febb3a2d3d78270d5be1cb24d
Reviewed-on: https://go-review.googlesource.com/c/go/+/379116
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
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>
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.
Reattempt at CL 372914, which was rolled back due to race-y
LocalPkg.Lookup call that isn't safe for concurrency.
Fixes#50190.
Change-Id: I0b7fd81e1b0b3199a6afcffde96ade42495ad8d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/378434
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
With this change, we shall now see:
*myS does not implement S (wrong type for DoSomething method)
have DoSomething() (string, error) at ./main.go:9:14
want DoSomething() (int, error)
instead of previously:
*myS does not implement S (wrong type for DoSomething method)
have DoSomething() (string, error)
want DoSomething() (int, error)
Fixes#42841Fixes#45813
Change-Id: I66990929e39b0d36f2e91da0d92f60586a9b84e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/373634
Trust: Robert Findley <rfindley@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The names given to methods of types created during type substitution
were possible incorrect when the type parameters themselves were nested
types.
Fixes#50485
Change-Id: I7e0043ed22c26406a5f9d8d51d9e928770a678f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/377494
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 loading of the base type in typ0() may cause s.Def to be defined for
the instantiated type, so load the base type before checking s.Def.
Fixes#50486
Change-Id: Ic039bc8f774dda534f4ccd1f920220b7a10dede6
Reviewed-on: https://go-review.googlesource.com/c/go/+/377094
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>
Issue #50552 is due to a problem with my recent improvement in the
interaction between generics and inlining. In markInlBody(), we now mark
dictionaries and shape methods for export, so they will be available for
any package that inlines the current inlineable function. But we need to
make sure that the dictionary and method symbols have actually been
resolved into Nodes (looked up in the import data), if they are not
already defined, so we can then mark them for export.
Improved header comment on Resolve().
Fixes#50552
Change-Id: I89e52d39d3b9894591d2ad6eb3a8ed3bb5f1e0a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/377714
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
For some reason, aix sometimes executes the bogus function body. This
should never happen as it lives in a no-execute section. It might be
a transient permission blip as the heap grows.
Add a small function to cleanup and synchronize the icache before
jumping to the bogus function to ensure it causes a panic, not SIGILL.
Fixes#44583
Change-Id: Iadca62d82bfb70fc62088705dac42a880a1208fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/377314
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
I made the default be that, where there are differences between types2
and -G=0 error messages, we want errorcheck tests to pass types2.
Typically, we can get errorcheck to pass on types2 and -G=0 if they give
the same number of error messages on the same lines, just different
wording. If they give a different number of error messages, then I made
types2 pass. I added an exception list for -G=0 to cover those cases
where -G=0 and types give different numbers of error messages.
Because types2 does not run if there are syntax errors, for several
tests, I had to split the tests into two parts in order to get all the
indicated errors to be reported in types2 (bug228.go, bug388.go,
issue11610.go, issue14520.go)
I tried to preserve the GCCGO labeling correctly (but may have gotten
some wrong). When types2 now matches where a GCCGO error previously
occurred, I transformed GCCGO_ERROR -> ERROR. When types2 no longer
reports an error in a certain place, I transformed ERROR -> GCCGO_ERROR.
When types2 reports an error in a new place, I used GC_ERROR.
The remaining entries in types2Failures are things that I think we
probably still need to fix - either actually missing errors in types2,
or cases where types2 gives worse errors than -G=0.
Change-Id: I7f01e82b322b16094096b67d7ed2bb39b410c34f
Reviewed-on: https://go-review.googlesource.com/c/go/+/372854
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- detect *interface case and report specific error
- replaced switch with sequence of if's for more clarity
- fixed isInterfacePtr: it applies to all interfaces, incl.
type parameters
- reviewed/fixed all uses of isInterfacePtr
- adjusted error messages to be consistently of the format
"type %s is pointer to interface, not interface"
Fixes#48312.
Change-Id: Ic3c8cfcf93ad57ecdb60f6a727cce9e1aa4afb5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/376914
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Added a test to make sure that the private methods of a local generic
type are properly exported, if there is a global variable with that
type.
Added comments in crawler.go, to give more detail and to give more about
the overall purpose.
Fixed one place where t.isFullyInstantiated() should be replaced by
isPtrFullyInstantiated(t), so that we catch pointers to generic types
that may be used as a method receiver.
Change-Id: I9c42d14eb6ebe14d249df7c8fa39e889f7cd3f22
Reviewed-on: https://go-review.googlesource.com/c/go/+/374754
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>
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.
Fixes#50190.
Change-Id: I025ceb09a86e00b7583d3b9885d612f5d6cb44fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/372914
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Finally figured out how to deal with the interaction between generics
and inlining. The problem has been: what to do if you inline a function
that uses a new instantiated type that hasn't been seen in the current
package? This might mean that you need to do another round of
function/method instantiatiations after inlining, which might lead to
more inlining, etc. (which is what we currently do, but it's not clear
when you can stop the inlining/instantiation loop).
We had thought that one solution was to export instantiated types (even
if not marked as exportable) if they are referenced in exported
inlineable functions. But that was quite complex and required changing
the export format. But I realized that we really only need to make sure
the relevant dictionaries and shape instantiations for the instantiated
types are exported, not the instantiated type itself and its wrappers.
The instantiated type is naturally created as needed, and the wrappers
are generated automatically while writing out run-time type (making use
of the exported dictionaries and shape instantiations).
So, we just have to make sure that those dictionaries and shape
instantiations are exported, and then they will be available without any
extra round of instantiations after inlining. We now do this in
crawler.go. This is especially needed when the instantiated type is only
put in an interface, so relevant dictionaries/shape instantiations are
not directly referenced and therefore exported, but are still needed for
the itab.
This fix avoids the phase ordering problem where we might have to keep
creating new type instantiations and instantiated methods after each
round of inlining we do.
Removed the extra round of instantiation/inlining that were added in the
previous fix. The existing tests
test/typeparam{geninline.go,structinit.go} already test this situation
of inlining a function referencing a new instantiated type.
Added the original example from issue 50121 as test (has 5 packages),
since it found a problem with this code that the current simpler test
for 50121 did not find.
Change-Id: Iac5d0dddf4be19376f6de36ee20a83f0d8f213b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/375494
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Similarly to what we do for the built-in function `copy`,
where we allow a string as 2nd argument to append, also
permit a type parameter constrained by string|[]byte.
While at it, change date in the manual.go2 test files so
that we don't need to constantly correct it when copying
a test case from that file into a proper test file.
Fixes#50281.
Change-Id: I23fed66736aa07bb3c481fe97313e828425ac448
Reviewed-on: https://go-review.googlesource.com/c/go/+/376214
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
types2 allows the conversion of a slice of a user-defined byte type B
(not builtin uint8 or byte) to string. But runtime.slicebytetostring
requires a []byte argument, so add in a CONVNOP from []B to []byte if
needed. Same for the conversion of a slice of user-defined rune types to
string.
I made the same change in the transformations of the old typechecker, so
as to keep tcConv() and transformConv() in sync. That fixes the bug for
-G=0 mode as well.
Fixes#23536
Change-Id: Ic79364427f27489187f3f8015bdfbf0769a70d69
Reviewed-on: https://go-review.googlesource.com/c/go/+/376056
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
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>
CL 352870 added extra phase for instantiation after inlining, to take
care of the new fully-instantiated types. However, when fetching inlined
body of these types's methods, we need to allow OADDR operations on
untyped expressions, the same as what main inlining phase does.
The problem does not show up, until CL 371554, which made the compiler
do not re-typecheck while importing, thus leaving a OXDOT node to be
marked as address taken when it's not safe to do that.
Fixes#50437
Change-Id: I20076b872182c520075a4f8b84230f5bcb05b341
Reviewed-on: https://go-review.googlesource.com/c/go/+/375574
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: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
For #50317.
Change-Id: I24ccf333c380283a36b573ef8fc3e7fcd71bd17f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376215
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Work-around for #50481: report an error for multiple
blank type parameters. It's always possible to use
non-blank names in those cases.
We expect to lift this restriction for 1.19.
For #50481.
Change-Id: Ifdd2d91340aac1da3387f7d80d46e44f5997c2a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/376058
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Move switch to enable method type parameters entirely
to the parser, by adding the mode AllowMethodTypeParams.
Ensure that the error messages are consistent.
Remove unnecessary code in the type checker.
Fixes#50317.
Change-Id: I4f3958722400bdb919efa4c494b85cf62f4002bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/376054
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>
This change implements field the access p.f where the type of p
is a type parameter with a structural constraint that is a struct
with a field f. This is only the fix for the type checker. The
compiler will need a separate CL.
This makes the behavior consistent with the fact that we can
write struct composite literals for type parameters with a
struct structural type.
For #50417.
For #50233.
Change-Id: I87d07e016f97cbf19c45cde19165eae3ec0bad2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/375795
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>
For #50439
Change-Id: Ifad6e6f8de42121c695b5a4dc56e0f6606e2917e
Reviewed-on: https://go-review.googlesource.com/c/go/+/375796
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
In the dict info, we need to save the SelectorExpr of a generic method
call when making its sub-dictionary entry. The generic method call will
eventually be transformed into a function call on the method shape
instantiation, so we may not always have the selector info available
when we need it to create a dictionary. We use this SelectorExpr as
needed if the relevant call node has already been transformed.
Similarly, we save the InstExpr of generic function calls, since the
InstExpr will be dropped when the function call is transformed to a call
to a shape instantiation. We use this InstExpr if the relevant function
call has already been transformed.
Added an extra generic function Some2 and a call to it from Some that
exercises the generic function case. The existing test already tests the
method call case.
Fixes#50264
Change-Id: I2c7c7d79a8e33ca36a5e88e64e913c57500c97f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/373754
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>
Since we use existing instantiations from the symbol table when possible
(to make sure each instantiation is unique), we need to pop
instantiations of local types when leaving the containing scope.
g.stmts() now pushes and pops scope, and we do a Pushdcl() in g.typ0()
when creating an instantiation of a local type.
Non-instantiated local types (generic or not) are translated directly
from types2, so they don't need to be pushed/popped. We don't export
function bodies with local types, so there is no issue during import.
We still don't support local types in generic functions/methods.
Fixes#50177
Change-Id: If2d2fe71aec003d13f0338565c7a0da2c9580a14
Reviewed-on: https://go-review.googlesource.com/c/go/+/372654
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 imported code is already typechecked. NodAddrAt typechecks its
argument, which is unnecessary here and leads to errors when
typechecking unexported field references in other packages' code.
Mark the node is question as already typechecked, so we don't
retypecheck it.
Fixes#50148
Change-Id: I9789e3e7dd4d58ec095675e27b1c98389f7a0c44
Reviewed-on: https://go-review.googlesource.com/c/go/+/371554
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Generic instantiations can produce conversions from constant
literal ints or floats to complex values. We could constant literals
during instantiation, but it is just as easy to upgrade the code
generator to do the conversions.
Fixes#50193
Change-Id: I24bdc09226c8e868f6282e0e4057ba6c3ad5c41a
Reviewed-on: https://go-review.googlesource.com/c/go/+/372514
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Thanks to the simpler test case for issue 50109. I'm keeping the old
test case in place, since it's not too complex, and may be useful for
testing other things as well.
Updates #50109
Change-Id: I80cdbd1da473d0cc4dcbd68e45bab7ddb6f9263e
Reviewed-on: https://go-review.googlesource.com/c/go/+/371515
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
The builtin "any" type should only be identical to an unnamed empty
interface type, not a defined empty interface type.
Fixes#50169.
Change-Id: Ie5bb88868497cb795de1fd0276133ba9812edfe4
Reviewed-on: https://go-review.googlesource.com/c/go/+/372217
Trust: Cherry Mui <cherryyz@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We delay all transformations on generic functions, and only do them on
instantiated functions, for several reasons, of which one is that
otherwise the compiler won't understand the relationship between
constrained type parameters. In an instantiation with shape arguments,
the underlying relationship between the type arguments are clear and
don't lead to compiler errors.
This issue is because I missed delaying assignment transformations for
variable declarations. So, we were trying to transform an assignment,
and the compiler doesn't understand the relationship between the T and U
type parameters.
The fix is to delay assignment transformations for variable declarations
of generic functions, just as we do already for normal assignment
statements.
A work-around for this issue would be to just separate the assignment
from the variable declaration in the generic function (for this case of
an assignment involving both of the constrained type parameters).
Fixes#50147
Change-Id: Icdbcda147e5c4b386e4715811761cbe73d0d837e
Reviewed-on: https://go-review.googlesource.com/c/go/+/371534
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
We can import an shape-instantiated function/method for inlining
purposes. If we are instantiating the methods of a instantiated type
that we have seen, and it happens to need a shape instantiation that we
have imported, then don't re-create the instantiation, since we will end
up with conflicting/duplicate definitions for the instantiation symbol.
Instead, we can just use the existing imported instantation, and enter
it in the instInfoMap[].
Fixes#50121
Change-Id: I6eeb8786faad71106e261e113048b579afad04fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/371414
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>
A "RET f(SB)" wasn't assembled correctly in a leaf function with
non-zero frame size. Follows CL 371034, for MIPS(32/64)(be/le)
and S390X. Other architectures seem to do it right. Add a test.
Change-Id: I41349a7ae9862b924f3a3de2bcb55b782061ce21
Reviewed-on: https://go-review.googlesource.com/c/go/+/371214
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
In identical(), we don't want any to match a shape empty-interface type
for the identStrict option, since IdenticalStrict() is specifically not
supposed to match a shape type with a non-shape type.
There is similar code in (*Type).cmp() (TINTER case), but I don't
believe that we want to disqualify shape types from matching any in this
case, since cmp() is used for back-end code, where we don't care about
shape types vs non-shape types.
The issue mainly comes about when 'any' is used as a type argument
(rather than 'interface{}'), but only with some complicated
circumstances, as shown by the test case. (Couldn't reproduce with
simpler test cases.)
Fixes#50109
Change-Id: I3f2f88be158f9ad09273237e1d346bc56aac099f
Reviewed-on: https://go-review.googlesource.com/c/go/+/371154
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>
Augmented some of the typeswitch*.go tests so that some instantiations
have duplicate cases, in order to ensure we're testing that.
Spacing changes in the tests are due to gofmt.
Change-Id: I5d3678813505c520c544281d4ac8a62ce7e236ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/370155
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>
Deal with case where a certain instantiation of a generic
function/method leads to an unsatisfiable type assertion or type case.
In that case, the compiler was causing a fatal error while trying to
create an impossible itab for the dictionary. To deal with that case,
allow ITabLsym() to create a dummy itab even when the concrete type
doesn't implement the interface. This dummy itab is analogous to the
"negative" itabs created on-the-fly by the runtime.
We will use the dummy itab in type asserts and type switches in
instantiations that use that dictionary entry. Since the dummy itab can
never be used for any real value at runtime (since the concrete type
doesn't implement the interface), there will always be a failure for the
corresponding type assertion or a non-match for the corresponding
type-switch case.
Fixes#50002
Change-Id: I1df05b1019533e1fc93dd7ab29f331a74fab9202
Reviewed-on: https://go-review.googlesource.com/c/go/+/369894
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 type was changed in https://golang.org/cl/3991043 but the comment
wasn't updated.
Change-Id: I7ba3f625c732e5e801675ffc5d4a28e1d310faa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/369374
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Make sure that we can import/export selects for generics.
Change-Id: Ibf36e98fc574ce9275820aa426b3e6703b0aae6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/369101
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Enable a bunch of types2-related error tests to run successfully, so
they no longer have to be disabled in run.go.
- directive.go: split it into directive.go and directive2.go, since the
possible errors are now split across the parser and noder2, so they
can't all be reported in one file.
- linkname2.go: similarly, split it into linkname2.go and linkname3.go
for the same reason.
- issue16428.go, issue17645.go, issue47201.dir/bo.go: handle slightly
different wording by types2
- issue5609.go: handle slight different error (array length must be
integer vs. array bound too large).
- float_lit3.go: handle slightly different wording (overflows
float vs cannot convert to float)
I purposely didn't try to fix tests yet where there are extra or missing
errors on different lines, since that is not easy to make work for both
-G=3 and -G=0. In a later change, will flip to make the types2 version
match correctly, vs. the -G=0 version.
Change-Id: I6079ff258e3b90146335b9995764e3b1b56cda59
Reviewed-on: https://go-review.googlesource.com/c/go/+/368455
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
First, we need to set base.Pos in varDecl() and typeDecl(), so it will
be correct if we need to report type size errors while converting types.
Changed error calls in types/sizes.go to use Errorf, not ErrorfAt, since
we want to use base.Pos (which will set from t.Pos(), if that is
available).
Second, we need to add an extra call CalcSize(t1.Elem()) in the
TCHANARGS case of CalcSize(). We can use CalcSize() rather than
CheckSize(), since we know the top-level recursive type will have been
calculated by the time we process the fake TCHANARGS type. In -G=0 mode,
the size of the channel element has often been calculated because of
some other processing (but not in the case of #49767). But in -G=3 mode,
we just calculate sizes during the single noder2 pass, so we are more
likely to have not gotten to calculating the size of the element yet,
depending on the order of processing of the deferredTypeStack.
Fixes the tests fixedbugs/issue{42058a,42058b}.go that were
disabled for -G=3 mode.
Had to add exceptions in stdlib_test.go for go/types and types2, because
the types2 typechecker does not know about type size limits.
Fixes#49814Fixes#49771
Updates #49767
Change-Id: I77d058e8ceff68a58c4c386a8cf46799c54b04c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/367955
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>
When we set g.curDecl for the type params created during fillinMethods
for an instantiated type, we need to save/restore its value, because
fillinMethods() may be called while processing a typeDecl. We want the
value of g.curDecl to continue to be correct for type params created in
the typeDecl. Because of ordering issues, not restoring g.curDecl
happens to cause problems (which don't always show up visibly) exactly
when a type param is not actually used in a type declaration.
Cleared g.curDecl to "" at the later points in typeDecl() and
funcDecl(). This allows adding asserts that g.curDecl is always empty
("") when we set it in typeDecl() and funcDecl(), and always non-empty
when we use it in typ0().
Fixes#49893
Change-Id: Ic2fb1df791585bd257f2b86ffaae0453c31705c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/368454
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Currently, identical handles any and interface{} by checking against
Types[TINTER]. This is not always true, since when two generated
interface{} types may not use the same *Type instance.
Instead, we must check whether Type is empty interface or not.
Fixes#49875
Change-Id: I28fe4fc0100041a01bb03da795cfe8232b515fc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/367754
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: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
