It was removed in CL 378576.
For #50501
Change-Id: I26b8f0e99a40fa5c616aa4849a6ab15dd0d072f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379314
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TestCPUProfileMultithreadMagnitude compares pprof results vs OS rusage
to verify that pprof is capturing all CPU usage. Presently it compares
the sum of cpuHog1 samples vs rusage. However, background usage from the
scheduler, GC, etc can cause additional CPU usage causing test failures
if rusage is too far off from the cpuHog1 samples.
That said, this test doesn't actually need to care about cpuHog1
samples. It simply cares that pprof samples match rusage, not what the
breakdown of usage was. As a result, we can compare the sum of _all_
pprof samples vs rusage, which should implicitly include any background
CPU usage.
Fixes#50097.
Change-Id: I649a18de5b3dcf58b62be5962fa508d14cd4dc79
Reviewed-on: https://go-review.googlesource.com/c/go/+/379535
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Document and enforce API expectation. Add a test so we don't
inadvertently change the function behavior with respect to nil
type arguments.
Fixes#50620.
Change-Id: Ic000bff7504a03006bd248a319c7a2d49dcf09c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379374
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This makes TestLabelSystemstack much more strict, enabling it to detect
any misplacement of labels.
Unfortunately, there are several edge cases where we may not have an
obviously correct stack trace, so we generally except the runtime
package, with the exception of background goroutines that we know should
not be labeled.
For #50007
For #50032
Change-Id: I8dce7e7da04f278ce297422227901efe52782ca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/369984
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
GC background mark worker goroutines are created when the first GC is
triggered (or next GC after GOMAXPROCS increases). Since the GC can be
triggered from a user goroutine, those workers will inherit any pprof
labels from the user goroutine.
That isn't meaningful, so avoid it by excluding system goroutines from
inheriting labels.
Fixes#50032
Change-Id: Ib425ae561a3466007ff5deec86b9c51829ab5507
Reviewed-on: https://go-review.googlesource.com/c/go/+/369983
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Instead, allow the test to run up until nearly the test's deadline,
whatever that may be, and then crash with a panic (instead of calling
t.Errorf) to get a useful goroutine dump.
With the arbitrary timeout removed, we can now also run this test in
short mode, reducing its impact on test latency.
Fixes#19381
Change-Id: Ie1fae321a2973fcb9b69a012103363f16214f529
Reviewed-on: https://go-review.googlesource.com/c/go/+/378034
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For an extension operation like MOWWreg, if the operand is already
extended, we optimize the second extension out. Usually a LoadReg
of a proper type would come already extended, as a MOVW/MOVWU etc.
instruction does. But for a LoadReg to a floating point register,
the instruction does not do the extension. So we cannot elide the
extension.
Fixes#50671.
Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3
Reviewed-on: https://go-review.googlesource.com/c/go/+/379236
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This test occasionally takes very slightly longer than the 3 second
timeout on slow builders (especially windows-386-2008), so increase
the timeout to 5 seconds. It fails with much longer timeouts on Plan
9, so skip it as flaky there.
Updates #41015.
Change-Id: I426a7adfae92c18a0f8a223dd92762b0b91565e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/379214
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This test was missed in CL 358539, presumably because the 'longtest'
builders lack a 'gpg' executable.
Updates #49168Fixes#50675
Change-Id: Ie3bfc761a5e4304531119625742f3def9df8af3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/378575
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently the code handles the case of returning values from
a function with no result parameters as a special case.
Consider this input:
package p
func f0_2() { return 1, 2 }
func f0_1() { return 1 }
func f1_0() int { return }
func f1_2() int { return 1, 2 }
func f2_0() (int, int) { return }
func f2_1() (int, int) { return 1 }
The errors are:
x.go:3:33: no result values expected <<<
x.go:4:33: no result values expected <<<
x.go:5:26: not enough return values
have ()
want (int)
x.go:6:36: too many return values
have (number, number)
want (int)
x.go:7:26: not enough return values
have ()
want (int, int)
x.go:8:33: not enough return values
have (number)
want (int, int)
There are two problems with the current special case emitting the
errors on the marked line:
1. It calls them 'result values' instead of 'return values'.
2. It doesn't show the type being returned, which can be useful to programmers.
Using the general case solves both these problems,
so this CL removes the special case and calls the general case instead.
Now those two errors read:
x.go:3:33: too many return values
have (number, number)
want ()
x.go:4:33: too many return values
have (number)
want ()
Fixes#50653.
Change-Id: If6b47dcece14ed4febb3a2d3d78270d5be1cb24d
Reviewed-on: https://go-review.googlesource.com/c/go/+/379116
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Consider the following program:
package p
func f() {
x := 1
v := 2
switch v.(type) {
case int:
println(x)
println(x / 0)
case 1:
}
}
Before this CL, the compiler prints:
x.go:4:2: x declared but not used
x.go:6:9: v (variable of type int) is not an interface
x is in fact used, and other errors in the switch go undiagnosed.
This commit fixes that problem by processing the switch statement
even when the 'not an interface' error is reported.
Now the compiler drops the spurious 'declared but not used'
and adds two previously undiagnosed problems:
x.go:6:9: v (variable of type int) is not an interface
x.go:9:15: invalid operation: division by zero
x.go:10:7: 1 is not a type
go/types was printing roughly the same thing the compiler did before,
and now still prints roughly the same thing the compiler does after.
(The only differences are in the exact reported columns.)
Fixes#50493.
Change-Id: I317883f29077b1b4bbd0e8793617fd3bb31aa0f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379117
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This extends the skip added in CL 375635 to the "_Headers" variant of
the test, since we have observed similar failures in that variant on
the builders.
For #43120
Change-Id: Ib1c97fbb776b576271629272f3194da77913a941
Reviewed-on: https://go-review.googlesource.com/c/go/+/379156
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
In the compiler, we need to distinguish field and method access on a
type param. For field access, we avoid the dictionary access (to create
an interface bound) and just do the normal transformDot() (which will
create the field access on the shape type).
This field access works fine for non-pointer types, since the shape type
preserves the underlying type of all types in the shape. But we
generally merge all pointer types into a single shape, which means the
field will not be accessible via the shape type. So, we need to change
Shapify() so that a type which is a pointer type is mapped to its
underlying type, rather than being merged with other pointers.
Because we don't want to change the export format at this point in the
release, we need to compute StructuralType() directly in types1, rather
than relying on types2. That implementation is in types/type.go, along
with the helper specificTypes().
I enabled the compiler-related tests in issue50417.go, added an extra
test for unnamed pointer types, and added a bunch more tests for
interesting cases involving StructuralType(). I added a test
issue50417b.go similar to the original example, but also tests access to
an embedded field.
I also added a unit test in
cmd/compile/internal/types/structuraltype_test.go that tests a bunch of
unusual cases directly (some of which have no structural type).
Updates #50417
Change-Id: I77c55cbad98a2b95efbd4a02a026c07dfbb46caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/376194
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#50501
(in a sense, by removing a flag that looks like it should do something
it does not)
Change-Id: I69ae4862706a6283cda4016fd43b361bb21557f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/378576
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We use uname -m to decide the GOHOSTARCH default,
and on my ARM64 Mac laptop, uname -m prints x86_64.
uname -a prints:
Darwin p1.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 x86_64
(Note the x86_64 at the end, consistent with uname -m.)
The effect of this is that make.bash builds an x86 toolchain
even when I start with an ARM64 bootstrap toolchain!
Avoid being tricked by looking for RELEASE_ARM64 instead.
Fixes#50643.
Change-Id: I76eded84bde8009d29419d5982bf964a0bf1c8fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/378894
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The VMOVQ instruction stores a 128-bit number into a V register, for
example:
VMOVQ $0x1122334455667788, $0x99aabbccddeeff00, V2
From a documentation (https://pkg.go.dev/cmd/internal/obj/arm64) point
of view, the value in V2 should be 0x112233445566778899aabbccddeeff00,
however the value is actually 0x99aabbccddeeff001122334455667788. The
reason is that we misplaced the high 64-bit and the low 64-bit in the
literal pool. To maintain backward compatibility, this CL adjusts the
rule of VMOVQ instruction to make the documentation consistent with the
code.
Fixes#50528
Change-Id: Ib51f59e97c55252ab2a50bbc6ba4d430732a7a04
Reviewed-on: https://go-review.googlesource.com/c/go/+/377055
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Trust: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, there are two regexps in the race detector output tests
that assume subtests will complete in < 1 second. This isn't necessary
and very occasionally fails (on builders that are probably very
loaded). Make these tests less picky about timing.
Fixes#50612.
Change-Id: Ib3f94d6c5dc37541dbeb06de71cf462a74af844b
Reviewed-on: https://go-review.googlesource.com/c/go/+/378581
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
As a follow-up to https://golang.org/cl/371474, add the OS version to
the metadata printed for each test.
Fixes#50146.
Change-Id: I3b7e47983d0e85feebce8e424881b931882d53bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/371475
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Knowing whether test failures are correlated with specific CPU models on
has proven useful on several issues. Log it for prior to testing so it
is always available.
internal/sysinfo provides the CPU model, but it is not available in the
bootstrap toolchain, so we can't access this unconditionally in
cmd/dist. Instead use a build-tagged file, as the final version of
cmd/dist will use the final toolchain.
The addition of new data to the beginning of cmd/dist output will break
x/build/cmd/coordinator's banner parsing, leaving extra lines in the log
output, though information will not be lost.
https://golang.org/cl/372538 fixes up the coordinator and should be
submitted and deployed before this CL is submitted.
For #46272.
For #49209.
For #50146.
Change-Id: I515d2ec58e4c0034b76bf624ecaab38f16146074
Reviewed-on: https://go-review.googlesource.com/c/go/+/371474
Trust: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
SHT_NOBITS sections do not occupy space in the file and their offset is
"conceptual", reading their data should return all zeroes instead of
reading bytes from the section that follows them.
Change-Id: Iaa9634792c1909c3e87dab841dd646cd6dcf9027
Reviewed-on: https://go-review.googlesource.com/c/go/+/375216
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also adjust other skips to actually call t.Skip, so that the test
correctly shows as skipped instead of passing.
For #50605
Change-Id: Ied482f231a879224c5a92e2c47a6b21c1593a7da
Reviewed-on: https://go-review.googlesource.com/c/go/+/378554
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The netpoll code was written long ago, when the
only multiprocessors that Go ran on were x86.
It assumed that an atomic store would trigger a
full memory barrier and then used that barrier
to order otherwise racy access to a handful of fields,
including pollDesc.closing.
On ARM64, this code has finally failed, because
the atomic store is on a value completely unrelated
to any of the racily-accessed fields, and the ARMv8
hardware, unlike x86, is clever enough not to do a
full memory barrier for a simple atomic store.
We are seeing a constant background rate of trybot
failures where the net/http tests deadlock - a netpollblock
has clearly happened after the pollDesc has begun to close.
The code that does the racy reads is netpollcheckerr,
which needs to be able to run without acquiring a lock.
This CL fixes the race, without introducing unnecessary
inefficiency or deadlock, by arranging for every updater
of the relevant fields to publish a summary as a single
atomic uint32, and then having netpollcheckerr use a
single atomic load to fetch the relevant bits and then
proceed as before.
Fixes#45211 (until proven otherwise!).
Change-Id: Ib6788c8da4d00b7bda84d55ca3fdffb5a64c1a0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/378234
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we export a shape instantiation, because a particular
fully-instantiated type is needed by an inlineable function, we possibly
export the body of the instantiation, if it is inlineable. In this case,
we should have been calling ImportedBody() to make sure that the
function body had already been read in (if it is actually imported from
another package).
Fixes#50598
Change-Id: I512d2bcc745faa6ff3a97e25bc8f46e2c2643d23
Reviewed-on: https://go-review.googlesource.com/c/go/+/378494
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Let T be a type parameter, and say we instantiate it with S, a type
that isn't pointer-like (e.g. a pair of ints, or as in 50182, a
slice). Then to call a method m on a variable of type T, the compiler
does essentially:
var v T = ...
i := (interface{m()})(v)
i.m()
The conversion at that second line allocates, as we need to make the
data word for an interface. And in the general case, that interface
may live an arbitrarily long time. But in this case, we know it
doesn't.
The data word of i has type *S. When we call i.m, we can't call S.m
directly. It is expecting an S, not a *S. We call through a wrapper
defined on *S, which looks like:
func (p *S) m() {
var s S = *p
s.m()
}
The value passed in for p is exactly the data word mentioned above. It
never escapes anywhere - the wrapper copies a type S variable out of
*p and p is dead after that. That means that in the situation where we
build an interface for the explicit purpose of calling a method on it,
and use that built interface nowhere else, the allocation of the data
word for that interface is known to die before the call returns and
thus can be stack allocated.
One tricky case is that although the allocation of the backing store
of the interface conversion doesn't escape, pointers we store *inside*
that allocation might escape (in fact they definitely will, unless we
can devirtualize the receiver).
Fixes#50182
Change-Id: I40e893955c2e6871c54ccecf1b9f0cae17871b0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/378178
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In order to make sure we export the dictionaries/shape methods for all
fully-instantiated types in inlineable functions, we need to descend
fully into types. For example, we may have a map type (e.g.
map[transactionID]Promise[*ByteBuffer]), where the key or value is a new
fully-instantiated type. So, I add a new checkFullyInst() traversal
function, which traverses all encountered types, but maintains a map, so
it only traverse it type once. We need to descend fully into interfaces,
structs, and methods, since a fully-instantiated type make occur in any
fields or arguments/results of methods, etc.
Fixes#50561
Change-Id: I88681a30384168539ed7229eed709f4e73ff0666
Reviewed-on: https://go-review.googlesource.com/c/go/+/378154
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.
Reattempt at CL 372914, which was rolled back due to race-y
LocalPkg.Lookup call that isn't safe for concurrency.
Fixes#50190.
Change-Id: I0b7fd81e1b0b3199a6afcffde96ade42495ad8d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/378434
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
It's too confusing to users to run go install in module mode, so run
it in workspace mode instead.
Fixes#50036
Change-Id: Ia99927bd98f54be4c42224a247543892045e3464
Reviewed-on: https://go-review.googlesource.com/c/go/+/377334
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
go work sync resets the state in the modload package before each
iteration where it updates the workspace modules' go.mod files. But
before this change it wasn't resetting the global state in the modfetch
package. This is necessary because the modfetch package keeps track of
the sums that will be written to go.sum. Further, the fetch caches
will update information about which modules are used when fetching
packages, and so those caches need to be cleared between each workspace
module.
Thanks bcmills for helping me debug!
Fixes#50038
Change-Id: I5679c18a80feb7c5194c4a5f7e7129c7d198ef7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/376655
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Adds simple fuzz targets to archive/tar, archive/zip, compress/gzip,
encoding/json, image/jpeg, image/gif, and image/png.
Second attempt, this time we don't use the archives in testdata when
fuzzing archive/tar, since those are rather memory intensive, and
were crashing a number of builders.
Change-Id: I4828d64fa4763c0d8c980392a6578e4dfd956e13
Reviewed-on: https://go-review.googlesource.com/c/go/+/378174
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
- support printing of expression and type lists in sprintf
- simplified some code in go/types/exprstring.go
- fixed a typo in syntax package
Change-Id: Ic4bc154200aad95958d5bc2904a9ea17cf518388
Reviewed-on: https://go-review.googlesource.com/c/go/+/377974
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a stop gap solution to avoid panics due to stack overflow
during type unification. While this doesn't address the underlying
issues (for which we are still investigating the correct approach),
it prevents a panic during compilation and reports a (possibly not
quite correct) error message.
If the programs are correct in the first place, manually providing
the desired type arguments is a viable work-around, resulting in
code that will continue to work even when the issues here are fixed
satisfactorily.
For #48619.
For #48656.
Change-Id: I13bb14552b38b4170b5a1b820e3172d88ff656ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/377954
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
If we have more than 2 arguments, we may have arguments with named and
unnamed types. If that is the case, permutate params and args such that
the arguments with named types are first in the list. This doesn't affect
type inference if all types are taken as is. But when we have inexact
unification enabled (as is the case for function type inference), when
a named type is unified with an unnamed type, unification proceeds with
the underlying type of the named type because otherwise unification would
fail right away. This leads to an asymmetry in type inference: in cases
where arguments of named and unnamed types are passed to parameters with
identical type, different types (named vs underlying) may be inferred
depending on the order of the arguments.
By ensuring that named types are seen first, order dependence is avoided
and unification succeeds where it can.
This CL implements the respectice code but keeps it disabled for now,
pending decision whether we want to address this issue in the first
place.
For #43056.
Change-Id: Ibe3b08ec2afe90a24a8c30cd1875d504bcc2ef39
Reviewed-on: https://go-review.googlesource.com/c/go/+/377894
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Type parameter lists are stored using ast.FieldLists. Update the
documentation to reflect that the enclosing delimiter may be a bracket.
Change-Id: Id103e7b38975e94a1b521f75695edc10408ad3dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/378014
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts CL 352109.
Reason for revert: causing OOM failures on several builders, and may cause OOMs for end users with small machines as well.
Change-Id: I58308d09919969d5a6512ee5cee6aa5c4af6769b
Reviewed-on: https://go-review.googlesource.com/c/go/+/377934
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Until now, CTI (constraint type inference) was run before
FTI (function type inference). This lead to situations
where CTI infered a type that is missing necessary methods
even though a function argument of correct type was given.
This can happen when constraint type inference produces a
inferred type that is the structural type of multiple types,
which then is an underlying type, possibly without methods.
This CL removes the initial CTI step; it is only applied
after FTI with type arguments is run, and again after FTI
with untyped arguments is run.
Various comments are adjusted to reflect the new reality.
Fixes#50426.
Change-Id: I700ae6e762d7aa00d742943a2880f1a1db33c2b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/377594
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Introduce a (local) notion of a set of representative types,
which serves as a representation/approximation of an
interface's actual type set. If the set of representative
types is is non-empty and finite, it corresponds to the set
of specific types of the interface.
In the implementation, the set of representative types serves
as a finite representation of an interface's type set, together
with the set of methods.
Change-Id: Ib4c6cd5e17b81197672e4247be9737dd2cb6b56f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376834
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
With this change, we shall now see:
*myS does not implement S (wrong type for DoSomething method)
have DoSomething() (string, error) at ./main.go:9:14
want DoSomething() (int, error)
instead of previously:
*myS does not implement S (wrong type for DoSomething method)
have DoSomething() (string, error)
want DoSomething() (int, error)
Fixes#42841Fixes#45813
Change-Id: I66990929e39b0d36f2e91da0d92f60586a9b84e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/373634
Trust: Robert Findley <rfindley@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The names given to methods of types created during type substitution
were possible incorrect when the type parameters themselves were nested
types.
Fixes#50485
Change-Id: I7e0043ed22c26406a5f9d8d51d9e928770a678f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/377494
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
