1
0
mirror of https://github.com/golang/go synced 2024-11-17 04:14:52 -07:00
Commit Graph

69 Commits

Author SHA1 Message Date
Keith Randall
10c8b7c1d7 [dev.typeparams] cmd/compile: use dictionary to convert arguments of ==, != to interfaces
When comparing a value whose type is a type parameter to an interface,
we need to convert that type parameter to an interface using the dictionary
entries.

Change-Id: I409c9e36e376fe4ef8163407d0fd4e84496d5b65
Reviewed-on: https://go-review.googlesource.com/c/go/+/334150
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>
2021-07-16 18:31:15 +00:00
Dan Scales
ed9e109dc9 [dev.typeparams] cmd/compile: fix small -G=3 issues for tests disabled in run.go
- set correct position for closure capture variable in (*irgen).use()
   (issue20250.go) Also, evaluate rhs, lhs in that order in assignment
   statements to match noder1 (affects ordering of closure variables).

 - make sure to set Assign flag properly in (*irgen).forStmt() for range
   variables which are map accesses (issue9691.go)

 - make sure CheckSize() is call on the base type for top-level types
   converted by (*irgen).typ() that are pointer types (issue20174.go and
   issue37837.go)

 - deal with parentheses properly in validation function
   (*irgen).validate() (issue17270.go)

 - avoid HasNil call on type TTYPEPARAM - types2 typechecker will have
   already checked validity of the typeparam having nil value (new test
   issue39755.go)

Change-Id: Ie68004d964698aea047e19e7dcd79b297e9d47ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/334733
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>
2021-07-16 18:30:16 +00:00
Robert Griesemer
3d8453e00e [dev.typeparams] cmd/compile/internal/types2: more consistent handling of predeclared "any"
Rather than removing "any" from the universe scope, keep it predeclared
but provide a better error message.

While at it, remove some unnecessary type assertions.

Change-Id: I10603274282ea6afc107f703ab194f32bd334dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/334911
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>
2021-07-16 04:41:47 +00:00
Robert Griesemer
4ff0e04c2e [dev.typeparams] cmd/compile/internal/types2: embedding stand-alone type parameters is not permitted
For #47127.

Change-Id: Ie979ff56ae7c2dd0e5ce0ff39588f98ae68b5ee9
Reviewed-on: https://go-review.googlesource.com/c/go/+/334151
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>
2021-07-14 23:33:52 +00:00
Dan Scales
1c783dc148 [dev.typeparams] Add optional sub-dict entry for typeparam bound calls
In the case that a generic function/method f does a method call on a
type param allowed by its bound, an instantiation of f may do a direct
method call of a concrete type or a method call defined on a generic
type, depending on whether the passed type in a concrete type or an
instantiated type with the appropriate method defined. See the test case
boundmethod.go added to this change.

In order to keep the dictionary format the same for all instantiations
of a generic function/method, I decided to have an optional
sub-dictionary entry for "bounds" calls. At the point that we are
creating the actual dictionary, we can then fill in the needed
sub-dictionary, if the type arg is an instantiated type, or a zeroed
dictionary entry, if type arg is not instantiated and the method will be
on a concrete type.

In order to implement this, I now fill in n.Selection for "bounds"
method calls in generic functions as well. Also, I need to calculate
n.Selection correctly during import for the case where it is now set -
method calls on generic types, and bounds calls on typeparams.

With this change, the dictionaries/sub-dictionaries are correct for
absdiff.go. The new test boundmethod.go illustrates the case where the
bound sub-dict entry is not used for a dictionary for stringify[myint],
but is used for a dictionary for stringify[StringInt[myint]].

Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457
Reviewed-on: https://go-review.googlesource.com/c/go/+/333456
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>
2021-07-12 16:09:57 +00:00
Dan Scales
501725032c [dev.typeparams] cmd/compile: handle derived types that are converted to interfaces
Up to this point, we were only handling typeparams that were converted
to empty or non-empty interfaces. But we have a dictionary entry for
each derived type (i.e. type derived from typeparams) as well. So, when
doing a conversion, look for the source type in both the type params and
derived types of the generic info, and then use the appropriate
dictionary entry.

Added some cases to ifaceconv.go (e.g. converting []T to an empty
interface).

Change-Id: I7bbad0128bec20ccccd93ae1d65c1ffd44ca79a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/333011
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>
2021-07-07 17:40:11 +00:00
Dan Scales
b4844c9f54 [dev.typeparams] cmd/compile: handle the (*T).M method expression with dictionaries
The (*T).M method expression is where M is a value method, but the type
(*T) is a pointer to the main type. In this case, after following any
embedded fields, we need to add an extra star operator when using the
receiver arg in the closure call.

Thanks to Cuong for finding/pointing out an example for this case
(typeparam/mdempsky/14.go) This example also shows that we now need the
ability to export/import OEFACE and OIDATA, which I added.

Change-Id: Ida0f81ce757fff78fec6276c60052ed71d207454
Reviewed-on: https://go-review.googlesource.com/c/go/+/333014
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
2021-07-07 17:31:57 +00:00
Matthew Dempsky
5c42b6a953 [dev.typeparams] test: add regress tests that fail(ed) with -G=3
This CL includes multiple test cases that exercise unique failures
with -G=3 mode that did not affect unified IR mode. Most of these were
found over a period of about 3 hours of manual experimentation.

Thanks to Cuong Manh Le for test cases 11 and 12.

Updates #46704.

Change-Id: Ia2fa619536732b121b6c929329065c85b9384511
Reviewed-on: https://go-review.googlesource.com/c/go/+/326169
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-07-07 11:12:24 +00:00
Matthew Dempsky
49ade6b298 [dev.typeparams] test: add expected failure mechanism
This CL changes the existing excluded-test mechanism into a
known-failure mechanism instead. That is, it runs the test regardless,
but only reports if it failed (or succeeded) unexpectedly.

It also splits the known failures list into fine-grain failure lists
for types2, types2 w/ 32-bit target, -G=3, and unified.

Updates #46704.

Change-Id: I1213cbccf1bab6a92d9bfcf0d971a2554249bbff
Reviewed-on: https://go-review.googlesource.com/c/go/+/332551
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-07-07 11:12:13 +00:00
Dan Scales
6dec18cc75 [dev.typeparams] cmd/compile: start using sub-dictionary entries where needed
Added new struct instInfo for information about an instantiation (of a
generic function/method with gcshapes or concrete types). We use this to
remember the dictionary param node, the nodes where sub-dictionaries
need to be used, etc. The instInfo map replaces the Stencil map in
Package.

Added code to access sub-dictionary entries at the appropriate call
sites. We are currently still calculating the corresponding main
dictionary, even when we really only need a sub-dictionary. I'll clean
that up in a follow-up CL.

Added code to deal with "generic" closures (closures that reference some
generic variables/types). We decided that closures will share the same
dictionary as the containing function (accessing the dictionary via a
closure variable). So, the getGfInfo function now traverses all the
nodes of each closure in a function that it is analyzing, so that a
function's dictionary has all the entries needed for all its closures as
well. Also, the instInfo of a closure is largely shared with its
containing function. A good test for generic closures already exists
with orderedmap.go.

Other improvements:
 - Only create sub-dictionary entries when the function/method
   call/value or closure actually has type params in it. Added new test
   file subdict.go with an example where a generic method has an
   instantiated method call that does not depend not have type params.

Change-Id: I691b9dc024a89d2305fcf1d8ba8540e53c9d103f
Reviewed-on: https://go-review.googlesource.com/c/go/+/331516
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>
2021-07-02 19:07:06 +00:00
Dan Scales
8767b87ab5 [dev.typeparams] cmd/compile: functions to create GC shape types/names for a concrete type
Created functions to create GC shape type and names, based on a proposal
from Keith. Kept unsigned and signed integer types as different, since
they have different shift operations.

Included adding in alignment fields where padding is
required between fields, even though that seems like it will be fairly
uncommon to use.

Added some extra unusual struct typeparams (for testing the gcshape
names/types) in index.go test.

Change-Id: I8132bbd28098bd933435b8972ac5cc0b39f4c0df
Reviewed-on: https://go-review.googlesource.com/c/go/+/329921
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>
2021-06-30 20:51:17 +00:00
Keith Randall
6a5f7e8498 [dev.typeparams] cmd/compile: use dictionary entries for more conversion cases
This CL handles I(x) where I is an interface type and x has
typeparam type.

Change-Id: Ib99de2b741d588947f5e0164255f6365e98acd8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/326189
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>
2021-06-29 21:50:53 +00:00
Matthew Dempsky
f4198f85d5 [dev.typeparams] cmd/compile: generate wrappers within unified IR
This CL extends unified IR to handle creating wrapper methods. There's
relatively little about this code that's actually specific to unified
IR, but rewriting this logic allows a few benefits:

1. It decouples unified IR from reflectdata.methodWrapper, so the
latter code can evolve freely for -G=3's needs. This will also allow
the new code to evolve to unified IR's wrapper needs, which I
anticipate will operate slightly differently.

2. It provided an opportunity to revisit a lot of the code and
simplify/update it to current style. E.g., in the process, I
discovered #46903, which unified IR now gets correctly. (I have not
yet attempted to fix reflectdata.methodWrapper.)

3. It gives a convenient way for unified IR to ensure all of the
wrapper methods it needs are generated correctly.

For now, the wrapper generation is specific to non-quirks mode.

Change-Id: I5798de6b141f29e8eb6a5c563e7049627ff2868a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330569
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-06-25 05:00:20 +00:00
Dan Scales
ddb09af1b8 [dev.typeparams] cmd/compile: add derived types and subdictionaries to dictionaries
This is code in progress to generate the two main other types of entries
in dictionaries:
 - all types in the instantiated function derived from the type
   arguments (which are currently concrete, but will eventually be
   gcshapes)
 - pointers (i.e. mainly the unique name) to all needed sub-dictionaries

In order to generate these entries, we now generate cached information
gfInfo about generic functions/methods that can be used for creating the
instantiated dictionaries. We use the type substituter to compute the
right type args for instantiated sub-dictionaries.

If infoPrintMode is changed to true, the code prints out all the
information gathered about generic functions, and also the entries in
all the dictionaries that are instantiated. The debug mode also prints
out the locations where we need main dictionaries in non-instantiated
functions.

Other changes:
 - Moved the dictionary generation back to stencil.go from reflect.go,
   since we need to do extra analysis for the new dictionary entries. In
   the process, made getInstantiation generate both the function
   instantiation and the associated dictionary.

 - Put in small change for now in reflect.go, so that we don't try
   generate separate dictionaries for Value[T].get and the
   auto-generated (*Value[T]).get.  The auto-generated wrapper shouldn't really
   need a dictionary.

 - Detected, but not handling yet, a new case which needs
   dictionaries - closures that have function params or captured
   variables whose types are derived from type arguments.

 - Added new tests in dictionaryCapture for use of method
   value/expressions in generic functions and for mutually recursive
   generic functions.

Change-Id: If0cbde8805a9f673a23f5ec798769c85c9c5359b
Reviewed-on: https://go-review.googlesource.com/c/go/+/327311
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>
2021-06-24 20:11:51 +00:00
Dan Scales
ee4fc0c1bc [dev.typeparams] Fix issues related to dictionaries and method calls with embedded fields
- Fix handling of method expressions with embedded fields. Fix an
   incorrect lookup for method expressions, which have only the
   top-level type (and don't have DOT operations for the embedded
   fields). Add the embedded field dot operations into the closure.

 - Don't need a dictionary and so don't build a closure if the last
   embedded field reached in a method expression is an interface value.

 - Fix methodWrapper() to use the computed 'dot' node in the
   generic-only part of the code.

 - For a method expression, don't create a generic wrapper if the last
   embedded field reached before the method lookup is an interface.

Copied cmd/compile/internal/types2/testdata/fixedbugs/issue44688.go2 to
test/typeparam/issue44688.go, made it fully runnable (rather than just
for compilation), and added a bunch more tests.

Change-Id: I90c1aa569e1c7272e986c9d2ae683e553c3a38a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/329550
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-06-23 23:38:05 +00:00
Matthew Dempsky
1ba2074440 [dev.typeparams] cmd/compile/internal/types2: support local defined types
This CL changes types2's instance hashing logic to include position
information for function-scope defined types as disambiguation. This
isn't ideal, but it worked for getting nested.go passing.

Updates #46592.

Change-Id: Id83ba0001f44af69b81260306cc8b05e44fc4f09
Reviewed-on: https://go-review.googlesource.com/c/go/+/327170
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
2021-06-16 21:38:50 +00:00
Matthew Dempsky
db7c868307 [dev.typeparams] test: add string quoting support to test/run.go
This CL copies go/build's splitQuoted function (used for parsing #cgo
directives within `import "C"` preambles) to parse test recipe
commands. In particular, this now allows writing "build" and "run"
tests that use -gcflags to pass multiple compiler flags.

Change-Id: I0d18a9c13a4ce24bbdfa1da8662c0498c93a6762
Reviewed-on: https://go-review.googlesource.com/c/go/+/327275
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-06-12 14:36:25 +00:00
Keith Randall
cf4b6dc48e [dev.typeparams] cmd/compile: allow conversions from type parameter to interface
When converting from a type param to an interface, allow it if
the type bound implements that interface.

Query: some conversions go through this path, some use another path?
The test does

   var i interface{foo()int} = x

but

   i := (interface{foo()int})(x)

works at tip.

Change-Id: I84d497e5228c0e1d1c9d76ffebaedce09dc45e8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/325409
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>
2021-06-07 19:53:38 +00:00
Dan Scales
201d55e637 [dev.typeparams] cmd/compile: create .dict Param in the package of the instantiated function
The instantiated functions are created in the source package of the
generic function, so all lookups of symbols should be relative to that
package, so all symbols are consistently in the source package.

Fixes #46575

Change-Id: Iba67b2ba8014a630c5d4e032c0f2f2fbaaedce65
Reviewed-on: https://go-review.googlesource.com/c/go/+/325529
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-06-07 19:34:39 +00:00
Keith Randall
bad388744b [dev.typeparams] cmd/compile: handle dictionaries for top-level instantiations
There's no outer function in these cases, so we won't be reading
the dictionary as a subdictionary from the outer scope's dictionary.
It will always be a compile-time constant.

Change-Id: I754b126652a6ffb62255734d53fcec29d77cfa9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/324949
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
2021-06-04 18:11:39 +00:00
Dan Scales
de61465156 [dev.typeparams] cmd/compile: allow inlining in instantiated functions
Change markType to scan generic types and methods, so that inlineable
functions inside generic functions/methods will be properly marked for
export, which means inlining inside instantiated functions will work
correctly.

Also, fix handling of closures for instantiated functions. Some code
needs to be adjusted, since instantiated functions/methods are compiled
as if in the package of the source generic function/type, rather than in
the local package. When we create the closure struct, we want to make
sure that the .F field has the same package as the other fields for the
closure variables. Also, we need to disable a check in tcCompLit() when
being done for an instantiated function, since fields of the closure
struct will be from the source package, not the local package.

Re-enabled part of the orderedmapsimp test that was disabled because of
these issues.

Change-Id: Ic4dba8917da0a36b17c0bdb69d6d6edfdf14104a
Reviewed-on: https://go-review.googlesource.com/c/go/+/324331
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-06-04 17:48:10 +00:00
Dan Scales
8e6dfe1b31 [dev.typeparams] cmd/compile: export/import of recursive generic types.
Deal with export/import of recursive generic types. This includes
typeparams which have bounds that reference the typeparam.

There are three main changes:

  - Change export/import of typeparams to have an implicit "declaration"
    (doDecl). We need to do a declaration of typeparams (via the
    typeparam's package and unique name), because it may be referenced
    within its bound during its own definition.

  - We delay most of the processing of the Instantiate call until we
    finish the creation of the top-most type (similar to the way we
    delay CheckSize). This is because we can't do the full instantiation
    properly until the base type is fully defined (with methods). The
    functions delayDoInst() and resumeDoInst() delay and resume the
    processing of the instantiations.

  - To do the full needed type substitutions for type instantiations
    during import, I had to separate out the type subster in stencil.go
    and move it to subr.go in the typecheck package. The subster in
    stencil.go now does node substitution and makes use of the type
    subster to do type substitutions.

Notable other changes:
 - In types/builtins.go, put the newly defined typeparam for a union type
   (related to use of real/imag, etc.) in the current package, rather
   than the builtin package, so exports/imports work properly.

 - In types2, allowed NewTypeParam() to be called with a nil bound, and
   allow setting the bound later. (Needed to import a typeparam whose
   bound refers to the typeparam itself.)

 - During import of typeparams in types2 (importer/import.go), we need
   to keep an index of the typeparams by their package and unique name
   (with id). Use a new map typParamIndex[] for that. Again, this is
   needed to deal with typeparams whose bounds refer to the typeparam
   itself.

 - Added several new tests absdiffimp.go and orderedmapsimp.go. Some of
   the orderemapsimp tests are commented out for now, because there are
   some issues with closures inside instantiations (relating to unexported
   names of closure structs).

 - Renamed some typeparams in test value.go to make them all T (to make
   typeparam uniqueness is working fine).

Change-Id: Ib47ed9471c19ee8e9fbb34e8506907dad3021e5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/323029
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-06-04 16:43:27 +00:00
Dan Scales
370ff5ff96 [dev.typeparams] test: update all the typeparam tests to use the new union/tilde syntax
Did a mix of tilde and non-tilde usage. Tilde notation is not quite
fully functional, so no tests are currently trying to distinguish
(fail/not fail) based on tilde usage.

Change-Id: Ib50cec2fc0684f9d9f3561c889fd44c7a7af458c
Reviewed-on: https://go-review.googlesource.com/c/go/+/324572
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>
2021-06-03 16:05:22 +00:00
Dan Scales
97cb0113a3 [dev.typeparams] cmd/compile: fix export/import of constants with typeparam type
A constant will have a TYPEPARAM type if it appears in a place where it
must match that typeparam type (e.g. in a binary operation with a
variable of that typeparam type). If so, then we must write out its
actual constant kind as well, so its constant val can be read in
properly during import.

Fixed some export/import tests which were casting some untyped constants
to avoid this problem.

Change-Id: I285ad8f1c8febbe526769c96e6b27acbd23050f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/324189
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-06-02 23:10:42 +00:00
Keith Randall
7b876def6c [dev.typeparams] cmd/compile: add dictionary argument to generic functions
When converting from a generic function to a concrete implementation,
add a dictionary argument to the generic function (both an actual
argument at each callsite, and a formal argument of each
implementation).

The dictionary argument comes before all other arguments (including
any receiver).

The dictionary argument is checked for validity, but is otherwise unused.
Subsequent CLs will start using the dictionary for, e.g., converting a
value of generic type to interface{}.

Import/export required adding support for LINKSYMOFFSET, which is used
by the dictionary checking code.

Change-Id: I16a7a8d23c7bd6a897e0da87c69f273be9103bd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/323272
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>
2021-06-02 20:23:12 +00:00
Cuong Manh Le
4b10e4c547 [dev.typeparams] cmd/compile: handle ONONAME in subster.node
Fixes #46472

Change-Id: I27802978fa0c3bb32a29e452165a6fcac93473bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/323731
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: Dan Scales <danscales@google.com>
2021-06-01 17:10:20 +00:00
Dan Scales
4ed6317e73 [dev.typeparams] cmd/compile: always generate (*T).M wrappers for instantiated methods
Always generate (*T).M wrappers for instantiated methods, even when the
instantiated method is being generated for another package (its source
package)

Added new function t.IsInstantiated() to check for fully-instantiated
types (generic type instantiated with concrete types, hence concrete
themselves). This function helps hide the representation of instantiated
types outside of the types package.

Added new export/import test setsimp.go that needs this change.

Change-Id: Ifb700db8c9494e1684c93735edb20f4709be5f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/322193
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-05-26 21:39:54 +00:00
Dan Scales
b7f7d1cd7b [dev.typeparams] cmd/compile: get type aliases working with generic types
Generic types can the source type of a type alias, so modify g.typ0() to
be able to deal with base generic types.

Added test aliasimp.go that tests aliasing of local generic types and
imported generic types.

Change-Id: I1c398193819d47a36b014cc1f9bb55107e9a565b
Reviewed-on: https://go-review.googlesource.com/c/go/+/322194
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-05-26 21:38:54 +00:00
Dan Scales
fd54ae8b0c [dev.typeparams] cmd/compile: adding union support in types1
Add union support in types1, and allow exporting of unions, and
importing unions back into types1 and types2.

Added new test mincheck.go/mincheck.dir that tests that type lists (type
sets) are correctly exported/imported, so that types2 gives correct
errors that an instantiation doesn't fit the type list in the type param
constraint.

Change-Id: I8041c6c79289c870a95ed5a1b10e4c1c16985b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/322609
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>
2021-05-26 15:33:02 +00:00
Dan Scales
d48f6d9f6f [dev.typeparams] Don't check typecheck(3) on transform, so no need to export/import it
We have a value typecheck(3) that indicates that a node in a generic
function still needs transformation (via the functions in transform.go).
But it is not very desirable to export/import the value of typecheck(3).
So, I changed the stenciling code to just try to transform all relevant
node types during node copy. Almost all tranform functions were already
idempotent. I only had to add an extra if check before calling
transformAssign() in the OAS case. We still use the typecheck(3) in
noder to determine when higher-nodes have to delay transformation
because one or more of their args are delaying transformation.

Added new test mapsimp.go that required these tranformations after import.

As an additional change, export/import of OINDEX requires exporting the
type using w.exoticType() rather than w.typ(), in order to handle
generic functions. Since generic functions can have pre-transform
operations, the index operation can have a tuple type (multiple return
from a map lookup).

Added printing of imported function bodies in -W=3 debug mode.

Change-Id: I220e2428dc5f2741e91db146f075eb5b6045f451
Reviewed-on: https://go-review.googlesource.com/c/go/+/322191
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
2021-05-24 22:17:33 +00:00
Dan Scales
4c50721cda [dev.typeparams] cmd/compile: Fix handling of Name nodes during stenciling
The name substitution for stenciling was incorrectly handling non-local
names. Made changes to explicitly built the vars[] name substitution map
based on the local variables (similar to what inlining substitution
does). Then, we we are stenciling a name node, we do NOT make a copy of
the name node if it is not in vars[], since it is then a reference to an
external name. Added new function localvar() to create the new nodes for
the local variables and put them in the vars[] map.

New test listimp2.go, added missing test calls in list2.go

Change-Id: I8946478250c7bf2bd31c3247089bd50cfeeda0fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/322190
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>
2021-05-24 22:16:09 +00:00
Dan Scales
5b1120fac7 [dev.typeparams] cmd/compile: fix handling of Nname field in (*subster).tstruct.
We want to keep the Nname references for external function references in
tstruct (not remove them, as is currently happening). We only change the
Nname reference (translate it) when it appears in subst.vars[].

New export/import test sliceimp.go which includes some of these external
function references.

Change-Id: Ie3d73bd989a16082f0cebfb566e0a7faeda55e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/321735
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>
2021-05-21 23:25:07 +00:00
Dan Scales
8d2b4cb6cc [dev.typeparams] cmd/compile: fixing import of comm clauses/closures in generic functions
Improvements:
 - Fix export/import of the default case of a select statement (was not
   dealing with nil Comm case)
 - Set properly the name of closure functions in imported generic
   functions

Added new test exporting/importing a reasonably large channel package,
chansimp.go.

Change-Id: If2ee12bd749e5df415f48ec4b629a2fa68a79dcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/321734
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>
2021-05-21 23:13:46 +00:00
Dan Scales
b1a398cf0f [dev.typeparams] cmd/compile: add import/export of calls to builtin functions
For generic functions, we have to leave the builtins in OCALL form,
rather than transform to specific ops, since we don't know the exact
types involved. Allow export/import of builtins in OCALL form.

Added new export/import test mapimp.go.

Change-Id: I571f8eeaa13b4f69389dbdb9afb6cc61924b9bf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/321750
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-05-21 17:14:19 +00:00
Dan Scales
ccbfbb1c33 [dev.typeparams] cmd/compile: export OFUNCINST and OSELRECV2 nodes (for generic functions)
Added new test typeparam/factimp.go and changed a bunch of other tests
to test exporting more generic functions and types.

Change-Id: I573d75431cc92482f8f908695cfbc8e84dbb36d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/321749
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2021-05-21 17:03:30 +00:00
Dan Scales
7b3ee6102d [dev.typeparams] cmd/compile: move to new export version, keep reading previous version
I added constants for the previous export versions, and for the final
generics export version. I also added a const for the current export
version. We can increment the current export version for unstable
changes in dev.typeparams, and eventally set it back to the generics
version (2) before release. Added the same constants in
typecheck/iexport.go, importer/iimport.go, and gcimporter/iimport.go,
must be kept in sync.

Put in the needed conditionals to be able to read old versions.

Added new export/import test listimp.dir.

Change-Id: I166d17d943e07951aa752562e952b067704aeeca
Reviewed-on: https://go-review.googlesource.com/c/go/+/319931
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>
2021-05-21 04:03:26 +00:00
Dan Scales
15ad61aff5 [dev.typeparams] cmd/compile: get export/import of generic types & functions working
The general idea is that we now export/import typeparams, typeparam
lists for generic types and functions, and instantiated types
(instantiations of generic types with either new typeparams or concrete
types).

This changes the export format -- the next CL in the stack adds the
export versions and checks for it in the appropriate places.

We always export/import generic function bodies, using the same code
that we use for exporting/importing the bodies of inlineable functions.

To avoid complicated scoping, we consider all type params as unique and
give them unique names for types1. We therefore include the types2 ids
(subscripts) in the export format and re-create on import. We always
access the same unique types1 typeParam type for the same typeparam
name.

We create fully-instantiated generic types and functions in the original
source package. We do an extra NeedRuntimeType() call to make sure that
the correct DWARF information is written out. We call SetDupOK(true) for
the functions/methods to have the linker automatically drop duplicate
instantiations.

Other miscellaneous details:
 - Export/import of typeparam bounds works for methods (but not
   typelists) for now, but will change with the typeset changes.

 - Added a new types.Instantiate function roughly analogous to the
   types2.Instantiate function recently added.

 - Always access methods info from the original/base generic type, since
   the methods of an instantiated type are not filled in (in types2 or
   types1).

 - New field OrigSym in types.Type to keep track of base generic type
   that instantiated type was based on. We use the generic type's symbol
   (OrigSym) as the link, rather than a Type pointer, since we haven't
   always created the base type yet when we want to set the link (during
   types2 to types1 conversion).

 - Added types2.AsTypeParam(), (*types2.TypeParam).SetId()

 - New test minimp.dir, which tests use of generic function Min across
   packages. Another test stringimp.dir, which also exports a generic
   function Stringify across packages, where the type param has a bound
   (Stringer) as well. New test pairimp.dir, which tests use of generic
   type Pair (with no methods) across packages.

 - New test valimp.dir, which tests use of generic type (with methods
   and related functions) across packages.

 - Modified several other tests (adder.go, settable.go, smallest.go,
   stringable.go, struct.go, sum.go) to export their generic
   functions/types to show that generic functions/types can be exported
   successfully (but this doesn't test import).

Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f
Reviewed-on: https://go-review.googlesource.com/c/go/+/319930
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>
2021-05-21 03:41:18 +00:00
Dan Scales
04f65d394c [dev.typeparams] cmd/compile: fix use of method values with stenciled methods
We were handling the case where an OFUNCINST node was used as a function
value, but not the case when an OFUNCINST node was used as a method
value. In the case of a method value, we need to create a new selector
expression that references the newly stenciled method.

To make this work, also needed small fix to noder2 code to properly set the
Sel of a method SelectorExpr (should be just the base method name, not
the full method name including the type string). This has to be correct,
so that the function created by MethodValueWrapper() can be typechecked
successfully.

Fixes #45817

Change-Id: I7343e8a0d35fc46b44dfe4d45b77997ba6c8733e
Reviewed-on: https://go-review.googlesource.com/c/go/+/319589
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
2021-05-12 22:25:00 +00:00
Keith Randall
f432d3fc41 cmd/compile: fix nongeneric closures in generic functions
Ensure that formal parameter Names are correctly copied and marked
with the correct Curfn. We need to ensure this even when the underlying
closure has no type parameters.

(Aside: it is strange that the types of things contain formal
parameter names that need to be copied. Maybe that's an underlying
larger problem that needs to be fixed.)

Fixes #45738

Change-Id: Ia13d69eea992ff7080bd44065115bc52eb624e73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313652
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>
2021-04-27 19:30:11 +00:00
Dan Scales
55c517a8b3 cmd/compile: fix handling of ir.CurFunc during stenciling
The transform functions (specifically transformArgs, which is used from
transformCall/transformReturn) require that ir.CurFunc is set correctly.
Since transformCall() is used on the call of an instantiated generic
function, we need to set ir.CurFunc correctly in stencil(). Also,
correctly save/restore ir.CurFunc in genericSubst().

Without this fix, ir.CurFunc can be nil when we call TransformCall()
from stencil(), which leads to some temp variables being added
incorrectly to ir.TodoFunc (which leads to the fatal panic in the
issue).

Fixes #45722

Change-Id: Iddf4a67d28f2100dde8cde5dbc9ca1e00dad6089
Reviewed-on: https://go-review.googlesource.com/c/go/+/313869
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>
2021-04-27 16:55:20 +00:00
Keith Randall
083a26c7d2 cmd/compile: propagate pragmas from generic function to stenciled implementation
Change-Id: I28a1910890659aaa449ffd2a847cd4ced5a8600d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310211
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
2021-04-15 00:29:05 +00:00
Dan Scales
bf634c76b2 cmd/compile: look for function in instantiations in all global assignments
Add in some missing global assignment ops to the list of globals ops
that should be traversed to look for generic function instantiations.
The most common other one for global assigments (and the relevant one
for this bug) is OAS2FUNC, but also look at global assigments with
OAS2DOTTYPE, OAS2MAPR, OAS2RECV, and OASOP.

Bonus small fix: get rid of -G=3 case in ir.IsAddressable. Now that we
don't call the old typechecker from noder2, we don't need this -G-3
check anymore.

Fixes #45547.

Change-Id: I75fecec55ea0d6f62e1c2294d4d77447ed9be6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/310210
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>
2021-04-15 00:14:55 +00:00
Dan Scales
f2717b31b5 cmd/compile: deal correctly with unnamed function params during stenciling
During substitution of the function type during stenciling, we must set
the Name nodes of the param/result fields of the func type. We get those
name nodes from the substituted Dcl nodes of the PPARAMS and PPARAMOUTs.
But we must check that the names match with the Dcl nodes, so that we
skip any param fields that correspond to unnamed (in) parameters.

Added a few tests to typelist.go by removing a variety of unneeded
function parameter names.

Change-Id: If786961b64549da6f18eeeb5060ea58fab874eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/305912
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>
2021-03-31 00:52:26 +00:00
Dan Scales
1318fb4a32 cmd/compile: handle partial type inference that doesn't require function args
Handle the case where types can be partially inferred for an
instantiated function that is not immediately called. The key for the
Inferred map is the CallExpr (if inferring types required the function
arguments) or the IndexExpr (if types could be inferred without the
function arguments).

Added new tests for the case where the function isn't immediately called
to typelist.go.

Change-Id: I60f503ad67cd192da2f2002060229efd4930dc39
Reviewed-on: https://go-review.googlesource.com/c/go/+/305909
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
2021-03-30 19:44:38 +00:00
Dan Scales
032ef4bbfc cmd/compile: fix creation of named generic types (setting of t.nod)
The correct setting of t.nod is needed when exporting types. Make sure
we create instantiated named types correctly so t.nod is set.

New test file interfacearg.go that tests this (by instantiating a type
with an interface). Also has tests for various kinds of method
expressions.

Change-Id: Ia7fd9debd495336b73788af9e35d72331bb7d2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/305730
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-30 04:48:27 +00:00
Dan Scales
eeadfa2d38 cmd/compile: fix various small bugs related to type lists
Fix various small bugs related to delaying transformations due to type
params. Most of these relate to the need to delay a transformation when
an argument of an expression or statement has a type parameter that has
a structural constraint. The structural constraint implies the operation
should work, but the transformation can't happen until the actual value
of the type parameter is known.

 - delay transformations for send statements and return statements if
   any args/values have type params.

 - similarly, delay transformation of a call where the function arg has
   type parameters. This is mainly important for the case where the
   function arg is a pure type parameter, but has a structural
   constraint that requires it to be a function. Move the setting of
   n.Use to transformCall(), since we may not know how many return
   values there are until then, if the function arg is a type parameter.

 - set the type of unary expressions from the type2 type (as we do with
   most other expressions), since that works better with expressions
   with type params.

 - deal with these delayed transformations in subster.node() and convert
   the CALL checks to a switch statement.

 - make sure ir.CurFunc is set properly during stenciling, including
   closures (needed for transforming return statements during
   stenciling).

New test file typelist.go with tests for these cases.

Change-Id: I1b82f949d8cec47d906429209e846f4ebc8ec85e
Reviewed-on: https://go-review.googlesource.com/c/go/+/305729
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>
2021-03-30 03:05:45 +00:00
Dan Scales
0265b6475f cmd/compile: replace calls to typecheck with transform functions
For additions, compares, and slices, create transform functions that do
just the transformations for those nodes by the typecheck package (given
that the code has been fully typechecked by types2). For nodes that have
no args with typeparams, we call these transform functions directly in
noder2. But for nodes that have args with typeparams, we have to delay
and call the tranform functions during stenciling, since we don't know
the specific types involved.

We indicate that a node still needs transformation by setting Typecheck
to a new value 3. This value means the current type of the node has been
set (via types2), but the node may still need transformation.

Had to export typcheck.IsCmp and typecheck.Assignop from the typecheck
package.

Added new tests list2.go (required delaying compare typecheck/transform
because of != compare in checkList) and adder.go (requires delaying add
typecheck/transform, since it can do addition for numbers or strings).

There are several more transformation functions needed for expressions
(indexing, calls, etc.) and several more complicated ones needed for
statements (mainly various kinds of assignments).

Change-Id: I7d89d13a4108308ea0304a4b815ab60b40c59b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303091
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-23 04:23:52 +00:00
Dan Scales
90b1ed1602 cmd/compile: get untyped constants working in generic functions
types2 will give us a constant with a type T, if an untyped constant is
used with another operand of type T (in a provably correct way). When we
substitute in the type args during stenciling, we now know the real type
of the constant. We may then need to change the BasicLit.val to be the
correct type (e.g. convert an int64Val constant to a floatVal constant).
Otherwise, later parts of the compiler will be confused.

Updated tests list.go and double.go with uses of untyped constants.

Change-Id: I9966bbb0dea3a7de1c5a6420f8ad8af9ca84a33e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303089
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-18 22:18:32 +00:00
Dan Scales
70d54df4f6 cmd/compile: getting more built-ins to work with generics
For Builtin ops, we currently stay with using the old
typechecker to transform the call to a more specific expression
and possibly use more specific ops. However, for a bunch of the
ops, we delay calling the old typechecker if any of the args have
type params, for a variety of reasons.

In the near future, we will start creating separate functions that do
the same transformations as the old typechecker for calls, builtins,
indexing, comparisons, etc. These functions can then be called at noder
time for nodes with no type params, and at stenciling time for nodes
with type params.

Remove unnecessary calls to types1 typechecker for most kinds of
statements (still need it for SendStmt, AssignStmt, ReturnStmt, and
SelectStmt). In particular, we don't need it for RangeStmt, and this
avoids some complaints by the types1 typechecker on generic code.

Other small changes:
 - Fix check on whether to delay calling types1-typechecker on type
   conversions. Should check if HasTParam is true, rather than if the
   type is directly a TYPEPARAM.

 - Don't call types1-typechecker on an indexing operation if the left
   operand has a typeparam in its type and is not obviously a TMAP,
   TSLICE, or TARRAY. As above, we will eventually have to create a new
   function that can do the required transformations (for complicated
   cases) at noder time or stenciling time.

 - Copy n.BuiltinOp in subster.node()

 - The complex arithmetic example in absdiff.go now works.

 - Added new tests double.go and append.go

 - Added new example with a new() call in settable.go

Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/301951
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-17 16:53:00 +00:00
Dan Scales
832a01aad4 cmd/compile: deal with comparable embedded in a constraint
Ignore an embedded type in an interface which is the predeclared
interface "comparable" (which currently can only be in a type
constraint), since the name doesn't resolve and the "comparable" type
doesn't have any relevant methods (for the purposes of the compiler).

Added new test case graph.go that needs this fix.

Change-Id: I2443d2c3dfeb9d0a78aaaaf91a2808ae2759d247
Reviewed-on: https://go-review.googlesource.com/c/go/+/301831
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-16 18:42:06 +00:00