aboutsummaryrefslogtreecommitdiff
path: root/test
AgeCommit message (Collapse)Author
2022-01-14cmd/compile: add call to ImportedBody() when exporting shape inst bodyDan Scales
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>
2022-01-13cmd/compile: descend through types to find fully-instantiated typesDan Scales
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>
2022-01-13cmd/compile: unique LinkString for renamed, embedded fieldsMatthew Dempsky
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>
2022-01-12cmd/compile/types2, go/types: add position for "have" in failed interface ↵Emmanuel T Odeke
satisfaction 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 #42841 Fixes #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>
2022-01-11cmd/compile: fix the names of methods created during type substitutionDan Scales
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>
2022-01-11cmd/compile: in typ0(), load base type before checking s.DefDan Scales
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>
2022-01-11cmd/compile: resolve dictionaries/shape methods in markInlBody, if neededDan Scales
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>
2022-01-11test: workaround SIGILL on issue11656 on aixPaul E. Murphy
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>
2022-01-11test: re-enable most go/tests that were disabled because of types2 differencesDan Scales
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>
2022-01-10go/types, types2: better error message when using *interface instead of ↵Robert Griesemer
interface - 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>
2022-01-10cmd/compile: use exact constant in go_asm.hIan Lance Taylor
Fixes #50523 Change-Id: Idab1b44d106250e9301d90ee6571f0ea51242dd9 Reviewed-on: https://go-review.googlesource.com/c/go/+/377074 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Liz Fong-Jones <lizf@honeycomb.io> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2022-01-10Revert "cmd/compile: unique LinkString for renamed, embedded fields"Matthew Dempsky
This reverts CL 372914. Reason for revert: missing synchronization Change-Id: I7ebb6de082cebb73741d803ff00e3465bbafab81 Reviewed-on: https://go-review.googlesource.com/c/go/+/377379 Trust: Dan Scales <danscales@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dan Scales <danscales@google.com> Trust: Matthew Dempsky <mdempsky@google.com>
2022-01-10cmd/compile, test: updated comments in crawler.go, added testDan Scales
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>
2022-01-10cmd/compile: unique LinkString for renamed, embedded fieldsMatthew Dempsky
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>
2022-01-10cmd/compile: fix interaction between generics and inliningDan Scales
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>
2022-01-07cmd/compile: accept string|[]byte-constrained 2nd argument in appendRobert Griesemer
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>
2022-01-07cmd/compile: fix conv of slice of user-define byte type to stringDan Scales
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>
2022-01-07cmd/compile: fix instantiation of types referenced during inliningCuong Manh Le
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>
2022-01-07test/typeparam: adjust test preamble (fix longtests)Robert Griesemer
For #50481. Change-Id: I27e6c6499d6abfea6e215d8aedbdd5074ff88291 Reviewed-on: https://go-review.googlesource.com/c/go/+/376216 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
2022-01-07test/typeparam: adjust test preamble (fix longtests)Robert Griesemer
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>
2022-01-07test/typeparam: adjust test preamble (fix longtests)Robert Griesemer
For #50417. Change-Id: Ic55727c454ec342354f7fbffd22aa350e0d392c2 Reviewed-on: https://go-review.googlesource.com/c/go/+/376174 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> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-01-07go/types, types2: disallow multiple blank type parametersRobert Griesemer
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>
2022-01-06cmd/compile: report type parameter error for methods only onceRobert Griesemer
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>
2022-01-06go/types, types2: implement field access for struct structural constraintsRobert Griesemer
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>
2022-01-06test: add test of incorrect gofrontend errorIan Lance Taylor
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>
2022-01-06cmd/compile/internal/types2: better error message for invalid range clauseRobert Griesemer
Fixes #50372. Change-Id: I8e4c0020dae42744cce016433e398e0b884bb044 Reviewed-on: https://go-review.googlesource.com/c/go/+/375475 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2022-01-04cmd/compile: save selector/inst info for generic method/function callsDan Scales
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>
2022-01-04cmd/compile: pop instantiations of local types when leaving scopeDan Scales
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>
2021-12-16cmd/compile: don't re-typecheck while importingKeith Randall
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>
2021-12-16cmd/compile: upgrade ssa to do (int or float) -> complexKeith Randall
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>
2021-12-15test: add simpler test for issue 50109Dan Scales
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>
2021-12-15cmd/compile: correct type identity comparison with "any"Cherry Mui
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>
2021-12-14cmd/compile: fix case where we didn't delay transformAssign in varDeclDan Scales
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>
2021-12-13cmd/compile: avoid re-instantiating method that is already importedDan Scales
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>
2021-12-13cmd/internal/obj: fix tail call in non-zero frame leaf function on MIPS and ↵Cherry Mui
S390X 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>
2021-12-13cmd/compile: fix identity case relating to 'any' and shape typesDan Scales
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>
2021-12-08test: add extra typeswitch tests that cause duplicate casesDan Scales
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>
2021-12-07cmd/compile: deal with unsatisfiable type assertion in some instantiationsDan Scales
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>
2021-12-05test/ken/slicearray.go: correct type width in commentIan Lance Taylor
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>
2021-12-03test: add test of select inside generic functionKeith Randall
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>
2021-12-03test: re-enable a bunch of tests with types2Dan Scales
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>
2021-12-02cmd/compile: report channel size errors correctly for -G=3Dan Scales
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 #49814 Fixes #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>
2021-12-02cmd/compile: fix case where g.curDecl should be saved/restoredDan Scales
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>
2021-12-01cmd/compile: fix identical to recognize any and interface{}Cuong Manh Le
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>
2021-11-26test/fixedbugs: fix go directive of issue16008.gosivchari
This change modifies issue16008.go I fixed // go:noinline to //go:noinline Change-Id: Ic133eec51f0a7c4acf8cb22d25473ca08f1e916c GitHub-Last-Rev: dd1868f2ca1f9ca7e2d6d1bfc15c601649896fdd GitHub-Pull-Request: golang/go#49801 Reviewed-on: https://go-review.googlesource.com/c/go/+/367174 Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Alberto Donizetti <alb.donizetti@gmail.com> Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-11-24cmd/compile/internal/types2: report types for mismatched call and return ↵Robert Griesemer
statements Thanks to emmanuel@orijtech.com who wrote the initial version of this change (CL 354490). This change is following CL 354490 in idea but also contains various simplifications, slightly improved printing of signature/type patterns, adjustments for types2, and some fine-tuning of error positions. Also adjusted several ERROR regexp patterns. Fixes #48834. Fixes #48835. Change-Id: I31cf20c81753b1dc84836dbe83a39030ceb9db23 Reviewed-on: https://go-review.googlesource.com/c/go/+/364874 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
2021-11-24cmd/compile/internal/inline: revise closure inl position fixThan McIntosh
This patch revises the fix for issue 46234, fixing a bug that was accidentally introduced by CL 320913. When inlining a chunk of code with a closure expression, we want to avoid updating the source positions in the function being closed over, but we do want to update the position for the ClosureExpr itself (since it is part of the function we are inlining). CL 320913 unintentionally did away with the closure expr source position update; here we restore it again. Updates #46234. Fixes #49171. Change-Id: Iaa51bc498e374b9e5a46fa0acd7db520edbbbfca Reviewed-on: https://go-review.googlesource.com/c/go/+/366494 Trust: Than McIntosh <thanm@google.com> Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com>
2021-11-22cmd/compile/internal/types2: print "nil" rather than "untyped nil"Robert Griesemer
When we have a typed nil, we already say so; thus it is sufficient to use "nil" in all the other cases. This is closer to (1.17) compiler behavior. In cases where the 1.17 compiler prints "untyped nil" (e.g., wrong uses of "copy"), we already print a different message. We can do better in those cases as well; will be addressed in a separate CL (see #49735). Fixes #48852. Change-Id: I9a7a72e0f99185b00f80040c5510a693b1ea80f6 Reviewed-on: https://go-review.googlesource.com/c/go/+/366276 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-11-20test: fix -G=0 mode for longtest builderDan Scales
For -G=3 for test using 'any'. Change-Id: Ia37ee944a38be4f4330e62ad187f10f2d42e41bd Reviewed-on: https://go-review.googlesource.com/c/go/+/365839 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2021-11-20cmd/compile: ensure generic function is loaded when it needs to be re-exportedDan Scales
In the case where we need to re-export a generic function/method from another package in the export data of the current package, make sure it is loaded before trying to write it out. Fixed #49667 Change-Id: I177754bb762689f34cf5c8ad246d43f1cdbbf195 Reviewed-on: https://go-review.googlesource.com/c/go/+/365837 Trust: Dan Scales <danscales@google.com> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion