After the previous two CLs, there's no need for unified IR to
write/read blank functions anymore: types2 has already checked that
they're valid, and the compiler backend is going to ignore them.
Allows dropping code for worrying about blank methods and will
probably simplify some of the object handling code eventually too.
Fixes#47446.
Change-Id: I03cb722793d676a246b1ab768b5cf0d3d2578b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/338096
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
After typechecking a blank function, we can clear out its body and
skip applying middle-end optimizations (inlining, escape analysis). We
already skip sending them through SSA, and the previous CL updated
inlining and escape analysis regress tests to not depend on compiling
blank functions.
Updates #47446.
Change-Id: Ie678763b0e6ff13dd606ce14906b1ccf1bbccaae
Reviewed-on: https://go-review.googlesource.com/c/go/+/338095
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL renames blank functions in the test/ directory so that they
don't rely on the compiler doing anything more than typechecking them.
In particular, I ran this search to find files that used blank
functions and methods:
$ git grep -l '^func.*\b_(' | xargs grep -n '^' | grep '\.go:1:' | grep -v '// errorcheck$'
I then skipped updating a few files:
* blank.go
* fixedbugs/issue11699.go
* fixedbugs/issue29870.go
These tests specifically check that blank functions/methods work.
* interface/fail.go
Not sure the motivation for the blank method here, but it's empty
anyway.
* typeparam/tparam1.go
Type-checking test, but uses "-G" (to use types2 instead of typecheck).
Updates #47446.
Change-Id: I9ec1714f499808768bd0dcd7ae6016fb2b078e5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/338094
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We don't usually reformat the test directory, but all of the files in
test/typeparam are syntactically valid. I suspect the misformattings
here are because developers aren't re-installing gofmt with
-tags=typeparams, not intentionally exercising non-standard
formatting.
Change-Id: I3767d480434c19225568f3c7d656dc8589197183
Reviewed-on: https://go-review.googlesource.com/c/go/+/338093
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This fixes a logic error introduced in CL 337850.
Fixes#47444
Change-Id: I6a49c8fc71fdde4ecb7f2e3329ad1f2cd286b7eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/338189
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
This is a port of CL 335929 to types2. It differs significantly from
that CL to handle lazy loading, which wasn't tested in go/types.
Additionally, the *Checker field was moved out of instance and back
onto Named. This way we can tell whether a Named type is uninstantiated
simply by checking whether Named.instance is non-nil, which simplified
the code considerably.
Fixes#46151
Change-Id: I617263bcfaa768ac5442213cecad8d567c2749fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/336252
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Ironically, checkptrAlignment had a latent case of bad pointer
arithmetic: if ptr is nil, then `add(ptr, size-1)` might produce an
illegal pointer value.
The fix is to simply check for nil at the top of checkptrAlignment,
and short-circuit if so.
This CL also adds a more explicit bounds check in checkptrStraddles,
rather than relying on `add(ptr, size-1)` to wrap around. I don't
think this is necessary today, but it seems prudent to be careful.
Fixes#47430.
Change-Id: I5c50b2f7f41415dbebbd803e1b8e7766ca95e1fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/338029
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Fix the cons.go missing method error. Mark all the methods of
instantiated interface types as used. We could try to record all the
exact methods used for generic interface types, but for now, just mark
all the methods as used so that their methods are not dead-code
eliminated.
Change-Id: I35685eda82476244371379b97691a1b8506ef0f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/337349
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>
When checking for updates, the go command checks whether the highest
compatible version has a go.mod file in order to determine whether
+incompatible versions may be considered "latest". Previously, to
perform this check, the go command would download the content of the
module (the .zip file) to see whether a go.mod file was present at the
root. This is slower than necessary, and it caused 'go list -m -u' to
try to save the sum for the .zip file in go.sum in some cases.
With this change, the go command only downloads the .mod file and
checks whether it appears to be a fake file generated for a version
that didn't have a go.mod file. This is faster and requires less
verification. Fake files only have a "module" directive. It's possible
to commit a file that passes this test, but it would be difficult to
do accidentally: Go 1.12 and later at least add a "go" directive. A
false positive here would cause version queries to have slightly
different results but would not affect builds.
Fixes#47377
Change-Id: Ie5ffd0b45e39bd0921328a60af99a9f6e5ab6346
Reviewed-on: https://go-review.googlesource.com/c/go/+/337850
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This removes the special "==" methods from comparable interfaces in
favor of a "comparable" flag in TypeSets indicating that the interface
is or embeds comparable. Fixes various related implementation
inaccuracies.
While at it, fix setup of the predeclared error and comparable
interface types by associating their respective type name objects
with them.
For #47411.
Change-Id: I409f880c8c8f2fe345621401267e4aaabd17124d
Reviewed-on: https://go-review.googlesource.com/c/go/+/337354
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
append is fine using shape types.
Change-Id: Iae829b9b5929d4dc7aa74bed57da13d4f6d746be
Reviewed-on: https://go-review.googlesource.com/c/go/+/337669
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>
Currently, deferproc stores the caller SP as a uintptr in a local
variable across a call to newdefer, but newdefer could grow the stack
and invalidate this saved SP, causing deferproc to store a stale SP in
the defer record. This would lead to us later failing to match that
defer to its calling frame, and we wouldn't run the defer at the right
time (or possibly at all).
It turns out this isn't crashing horribly right now only because the
compiler happens to only materialize the result of getcallersp when
this variable is used, *after* the call to newdefer. But this is
clearly on thin ice, so this CL moves the getcallersp() to the place
where we actually need the result.
Change-Id: Iae8ab226e03e4482f16acfb965885f0bd83a13b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/337649
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
According to the discussion, it is clear that T.Name returns a
distinct name among all tests. However, there is no specification
of how sub-tests with the same specified test name are constructed.
This change only clarifies the uniqueness and the components of the
name without suggesting any explicit format of the returned name.
Fixes#46488
Change-Id: I6cebd419b69fb08d8646cb744a129548452042ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/337392
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
CL 291316 fixed go/types to verify that untyped shift counts are
representable by uint, but as a side effect also converted their types
to uint.
Rearrange the logic to keep the check for representability, but not
actually convert untyped integer constants. Untyped non-integer
constants are still converted, to preserve the behavior of 1.16. This
behavior for non-integer types is a bug, filed as #47410.
Updates #47410Fixes#47243
Change-Id: I5eab4aab35b97f932fccdee2d4a18623ee2ccad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/337529
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In CL 336432 we changed adjusttimers so that it no longer cleared
timerModifiedEarliest if there were no timersModifiedEarlier timers.
This caused some Google internal tests to time out, presumably due
to the increased contention on timersLock. We can avoid that by
simply not skipping the loop in adjusttimers, which lets us safely
clear timerModifiedEarliest. And if we don't skip the loop, then there
isn't much reason to keep the count of timerModifiedEarlier timers at all.
So remove it.
The effect will be that for programs that create some timerModifiedEarlier
timers and then remove them all, the program will do an occasional
additional loop over all the timers. And, programs that have some
timerModifiedEarlier timers will always loop over all the timers,
without the quicker exit when they have all been seen. But the loops
should not occur all that often, due to timerModifiedEarliest.
For #47329
Change-Id: I7b244c1244d97b169a3c7fbc8f8a8b115731ddee
Reviewed-on: https://go-review.googlesource.com/c/go/+/337309
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Change-Id: I5eb03ae349925f0799dd866e207221429bc9fb3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/337353
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>
Change-Id: I95a96f9dbd199cee3a4be8f42cd64e7f44ba5e5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/336989
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a straight port of https://golang.org/cl/330431.
For #43232
Change-Id: I5954bdff22a524eaa08754947da9b428b27f7d95
Reviewed-on: https://go-review.googlesource.com/c/go/+/336351
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>
This is a partial port of https://golang.org/cl/330629, containing
only the actual bug fix and adjustements to another test file.
The respective test case has not been ported yet as it requires
some bigger adjustments.
For #46905
Change-Id: Ibd20658b8a31855da20cf56e24bcce9560656ca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/336350
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Conflicts:
- src/cmd/compile/internal/ssagen/ssa.go
CL 336629 touched code that had already been removed on dev.typeparams.
Merge List:
+ 2021-07-26 ecaa6816bf doc: clarify non-nil zero length slice to array pointer conversion
+ 2021-07-26 1868f8296e crypto/x509: update iOS bundled roots to version 55188.120.1.0.1
+ 2021-07-25 849b791129 spec: use consistent capitalization for rune literal hex constants
+ 2021-07-23 0914646ab9 doc/1.17: fix two dead rfc links
+ 2021-07-22 052da5717e cmd/compile: do not change field offset in ABI analysis
Change-Id: Ie570ec3f6a3241e0495e39e8a73b3a09a9368605
This CL changes fixedbugs/issue30862.go into a "runindir" test so that
it can use '-goexperiment fieldtrack' and test that //go:nointerface
works with cmd/compile. In particular, this revealed that -G=3 and
unified IR did not handle it correctly.
This CL also fixes unified IR's support for //go:nointerface and adds
a test that checks that //go:nointerface, promoted methods, and
generics all interact as expected.
Updates #47045.
Change-Id: Ib8acff8ae18bf124520d00c98e8915699cba2abd
Reviewed-on: https://go-review.googlesource.com/c/go/+/332611
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
There is an example for nil slice already, so adding example for non-nil
zero length slice, too, clarifying to the reader that the result is also
non-nil and different from nil slice case.
Updates #395
Change-Id: I019db1b1a1c0c621161ecaaacab5a4d888764b1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/336890
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
HasShape needs a TINTER case.
Add a test for x.(T) in various situations. Needs the fix above.
Also remove ONEW unshapify case. It is ok for ONEW to have a shape
type, as it will just be passed to mallocgc, or possibly used as a
stack object type, both of which are ok.
Change-Id: Ibddf8f5c8c254d32cb5ebcaca7dc94b4c00ab893
Reviewed-on: https://go-review.googlesource.com/c/go/+/337231
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>
Fixes -G=3 issue with issue44688.go.
Change-Id: Ie98c0cbd48683dedd115332043f14c8f3160f46c
Reviewed-on: https://go-review.googlesource.com/c/go/+/337029
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>
We just need to substitute from the typeparams to the shapes for the dst
type of the bound.
Removed concretify substituter, not used anymore. Also removed
shape2params, not needed anymore.
However, since the dst type is now not concrete, this gives more cases
where the linker can't find a method.
I realized that we need to call MarkUsedIfaceMethod to mark a method as
used on a particular interface, else a type's method can be still
deadcoded even though MarkTypeUsedInInterface has been called on the
concrete type. I added a new version MarkUsedIfaceMethodIndex to fit my
use case.
Change-Id: Id67b72b350889dd3688b42739c337d5d79a0d1a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/337230
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This operation computes just the data field needed to put its argument
into an interface. Used by generics because we produce the type field
of an interface using dictionaries (instead of statically).
With this operation defined, we can now assert that shape types
are never marked as used in interfaces (the only previous use
was IDATA(CONVIFACE(t))).
Change-Id: Idb1eb5f3b238285cb99413d382599c0621b7681a
Reviewed-on: https://go-review.googlesource.com/c/go/+/337109
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>
As of CL 334894, type sets are lazily evaluated on interfaces. For the
universe interfaces error and comparable, this can lead to data races
when type checking concurrently. Fix this by computing their type set
when they are defined.
Tested using the repro from #47345. I considered checking this in as a
test, but it probably wouldn't add much value going forward.
Fixes#47345
Change-Id: I014a511b8e3c092c86201a8bfc7f5f494f8f20e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/336910
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add a test to make sure there's no invalid OCONVIFACEs when stenciling is done.
Use concrete types for the type of DOTTYPE and DOTTYPE2.
MarkTypeUsedInInterface - should we allow types with shape types
underneath? I think the itab CL will help with this (at least, for
a remaining cons.go issue).
Change-Id: I2c96d74e8daaca26cadc84ea94abb9a27c0bb240
Reviewed-on: https://go-review.googlesource.com/c/go/+/337069
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>
Even if we can otherwise transform a return statement because of type
params, add CONVIFACE nodes where appropriate.
Change-Id: Ia2216d5f6805926075ba6802a4385eee1d63e37e
Reviewed-on: https://go-review.googlesource.com/c/go/+/337049
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>
This fix the case where a type param or derived type is converted to a
non-empty interface. Previously, we were converting to an empty
interface and then using DOTTYPE to convert to the correct non-empty
interface. In that case, we can get the needed itab directly from the
dictionary. This is needed for correctness from shapes, if the
destination interface is parameterized, else we will incorrectly convert
to the shape version of the interface.
Creating/writing an itab can involve generating wrappers for a bunch of
methods, which may use dictionaries. So, all the
dictionaries/instantiations are being generated on the fly and have
recursive relationships, it is simplest to finish creating/writing the
itabs at the end of the stenciling phase. So, we create a list of the
dictionaries which need to be completed by writing out their itab
entries.
The existing tests ordered.go, ifaceconv.go, and issue44688.go make use
of this optimization.
Got itab conversions for bound calls working, except for 13.go.
Also, want to get rid of the concretify, but I think we need more info
on the Bound from types2.
Change-Id: If552958a7b8a435500d6cc42c401572c367b30d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336993
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>
Changes to add CONVIFACE nodes where possible in noder2, even when the
args are typeparams. The transformation to insert a CONVIFACE node can
usually happen when there an obvious assignment/conversion to an
interface type from a non-interface type. So, we now do this
tranformation for:
- direct conversions to an interface type
- function arguments that are implicitly converted to an interface
based on the parameter types.
- EQ/NE comparison of an interface and a non-interface
With this change, we can remove some special case checks for CONVIFACE
nodes after transformation in node(), and instead just have the one
check in the CONVIFACE check.
Change-Id: I7cf2ef920aebf9e5553210aeaf19f344e128ca62
Reviewed-on: https://go-review.googlesource.com/c/go/+/336992
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Updates #44513
Change-Id: Ia0c6b48bde2719f3a99cb216b6166d82159198d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336930
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously it was just printing <S>. Now it prints things like int32|~int64.
Change-Id: I960b011ce8ed360020a49ae7809d85d1d1fdbfb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/336692
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>
Currently, the ABI analysis assigns parameter/result offsets
to the fields of function *Type. In some cases, we may have
an ABI0 function reference and an ABIInternal reference share
the same function *Type. For example, for an ABI0 function F,
"f := F" will make f and (ABI0) F having the same *Type. But f,
as a func value, should use ABIInternal. Analyses on F and f will
collide and cause ICE.
Also, changing field offsets in ABI analysis has to be done very
carefully to avoid data races. It has been causing
trickiness/difficulty.
This CL removes the change of field offsets in ABI analysis
altogether. The analysis result is stored in ABIParamAssignment,
which is the only way to access parameter/result stack offset now.
Fixes#47317.
Fixes#47227.
Change-Id: I23a3e081a6cf327ac66855da222daaa636ed1ead
Reviewed-on: https://go-review.googlesource.com/c/go/+/336629
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
I don't know what this test is doing, but it very frequently flakes
for me while testing mundane compiler CLs. According to the issue log,
it's been flaky for ~3 years.
Updates #37331.
Change-Id: I81c43ad646ee12d4c6561290a54e4bf637695bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/336349
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This avoids a race when a new timerModifiedEarlier timer is created by
a different goroutine.
Fixes#47329
Change-Id: I6f6c87b4a9b5491b201c725c10bc98e23e0ed9d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336432
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Make sure the instantiating types are the type parameters of the containing
function (or types derived from those).
The one exception is the argument of a OFUNCINST, whose type
parameters are those of the declaration site of the function or method
being instantiated. We skip those types.
Change-Id: I4b3ff22eb8a81a76476930cf8ed2a7dd6489d8b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/336352
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
We now understand the root cause of #47227, it will be fixed in #47317.
Change-Id: Ifcd44f887a0bd3195818df33e409bd3e818e0b27
Reviewed-on: https://go-review.googlesource.com/c/go/+/336610
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Changed the implementation such that the result is a variable rather than
a constant if the argument type (or the struct in case of unsafe.Offsetof)
has a size that depends on type parameters.
Minor unrelated adjustments.
For #40301.
Change-Id: I1e988f1479b95648ad95a455c764ead829d75749
Reviewed-on: https://go-review.googlesource.com/c/go/+/335413
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>
CL 330670 simplified usemethod, but dropped the previous condition to
ensure the function have 1 or 2 result. This CL restore that condition,
and also add a test for it.
Change-Id: I434e3736785b43ceea0b386d8d9d01ad78a4ccd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/336609
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Even internally to the type checker, we should use the TParams and
RParams methods instead of accessing fields directly, as TParams may be
lazily expanded, and in the future we may want to pack receiver and
function type parameters into a single field on Signature.
We should also not differentiate a nil *TParamList from an empty
*TParamList.
Change-Id: I85c616e6c708a89b6a5eb1e69fe0b014276eda90
Reviewed-on: https://go-review.googlesource.com/c/go/+/336251
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
It is invalid to use a type parameter for more than one type, so we can
avoid passing the type parameter index to NewTypeParam and just set it
when type parameters are bound to a type via SetTParams or during type
checking.
In order to enforce the correctness of this change, introduce a
TypeParams type to represent a list of type parameters that have been
associated with a type. For now, expose this new type as the API for
type parameters, but this is of course not necessarily a final API.
Allowing *TypeParams to be nil also decreases the size of Named and
Signature, which is good as most instances of these types will not be
parameterized.
Change-Id: Ia1e39ba51edb05bb535eb5f41c34e9dd02d39c38
Reviewed-on: https://go-review.googlesource.com/c/go/+/336249
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL makes two related changes:
1. It uses 'go env -json' to query the environment configuration,
rather than attempting to manually reconstruct the values that cmd/go
is going to use.
2. It changes the -goexperiment flag to *extend* any ambient
GOEXPERIMENT configuration. Notably, this means that '-goexperiment
fieldtrack' now tests fieldtracking in conjunction with any other
experiments (e.g., unified IR). Tests that want to test an exact
GOEXPERIMENT config should use '-goexperiment none,foo' instead.
Change-Id: I96a97198209e540e934fe7035110c3ae3a8f0e6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/332610
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
