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>
The loading of the base type in typ0() may cause s.Def to be defined for
the instantiated type, so load the base type before checking s.Def.
Fixes#50486
Change-Id: Ic039bc8f774dda534f4ccd1f920220b7a10dede6
Reviewed-on: https://go-review.googlesource.com/c/go/+/377094
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Issue #50552 is due to a problem with my recent improvement in the
interaction between generics and inlining. In markInlBody(), we now mark
dictionaries and shape methods for export, so they will be available for
any package that inlines the current inlineable function. But we need to
make sure that the dictionary and method symbols have actually been
resolved into Nodes (looked up in the import data), if they are not
already defined, so we can then mark them for export.
Improved header comment on Resolve().
Fixes#50552
Change-Id: I89e52d39d3b9894591d2ad6eb3a8ed3bb5f1e0a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/377714
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
We now may have a scope associated with a type declaration, so need to
update our API documentation accordingly.
Change-Id: Ic66dc3b7cd1969b25fb7c4bee986d76ab3544042
Reviewed-on: https://go-review.googlesource.com/c/go/+/377655
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>
Change hidePanic (now renamed handlePanic) to print out the "internal
compiler error" message for all panics and runtime exceptions, similar
to what we already do for the SSA backend in ssa.Compile().
Previously, hidePanic would not catch panics/exceptions unless it wanted
to completely hide the panic because there had already been some
compiler errors.
Tested by manually inserting a seg fault in the compiler, and verifying
that the seg fault is cause and "internal compiler error" message (with
stack trace) is displayed proeprly.
Updates #50423
Change-Id: Ibe846012e147fcdcc63ac147aae4bdfc47bf5a58
Reviewed-on: https://go-review.googlesource.com/c/go/+/376057
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Explain the conditions under which they are called on stacks that
cannot grow.
Change-Id: I08ee5480face7fbedeccc09e55b8149c5a793c2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/376036
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Fannie Zhang <Fannie.Zhang@arm.com>
For some reason, aix sometimes executes the bogus function body. This
should never happen as it lives in a no-execute section. It might be
a transient permission blip as the heap grows.
Add a small function to cleanup and synchronize the icache before
jumping to the bogus function to ensure it causes a panic, not SIGILL.
Fixes#44583
Change-Id: Iadca62d82bfb70fc62088705dac42a880a1208fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/377314
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
I made the default be that, where there are differences between types2
and -G=0 error messages, we want errorcheck tests to pass types2.
Typically, we can get errorcheck to pass on types2 and -G=0 if they give
the same number of error messages on the same lines, just different
wording. If they give a different number of error messages, then I made
types2 pass. I added an exception list for -G=0 to cover those cases
where -G=0 and types give different numbers of error messages.
Because types2 does not run if there are syntax errors, for several
tests, I had to split the tests into two parts in order to get all the
indicated errors to be reported in types2 (bug228.go, bug388.go,
issue11610.go, issue14520.go)
I tried to preserve the GCCGO labeling correctly (but may have gotten
some wrong). When types2 now matches where a GCCGO error previously
occurred, I transformed GCCGO_ERROR -> ERROR. When types2 no longer
reports an error in a certain place, I transformed ERROR -> GCCGO_ERROR.
When types2 reports an error in a new place, I used GC_ERROR.
The remaining entries in types2Failures are things that I think we
probably still need to fix - either actually missing errors in types2,
or cases where types2 gives worse errors than -G=0.
Change-Id: I7f01e82b322b16094096b67d7ed2bb39b410c34f
Reviewed-on: https://go-review.googlesource.com/c/go/+/372854
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Follow-up on comment in CL 376914.
Also:
- add missing check != nil test in assignableTo
- use check.sprintf rather than fmt.Sprintf in missingMethodReason
For #48312.
Change-Id: Ie209b4101a7f2c279e42a59987d0068079c8b69f
Reviewed-on: https://go-review.googlesource.com/c/go/+/377375
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Fixes#50516.
Also call DefPredeclaredTestFuncs in TestFixedbugs so it can be
run independently again.
Change-Id: I78d4cc11790b1543a2545a7ab297a223b3d5e3c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/376954
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- detect *interface case and report specific error
- replaced switch with sequence of if's for more clarity
- fixed isInterfacePtr: it applies to all interfaces, incl.
type parameters
- reviewed/fixed all uses of isInterfacePtr
- adjusted error messages to be consistently of the format
"type %s is pointer to interface, not interface"
Fixes#48312.
Change-Id: Ic3c8cfcf93ad57ecdb60f6a727cce9e1aa4afb5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/376914
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Only snapshot/reset coverage counters when we are actually fuzzing.
This prevents a race when running corpus/seed values during the testing
phase.
Fixes#50488
Change-Id: I7dd5a0353a296c0b13eede29ad9af7c78814fa2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/376554
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Added a test to make sure that the private methods of a local generic
type are properly exported, if there is a global variable with that
type.
Added comments in crawler.go, to give more detail and to give more about
the overall purpose.
Fixed one place where t.isFullyInstantiated() should be replaced by
isPtrFullyInstantiated(t), so that we catch pointers to generic types
that may be used as a method receiver.
Change-Id: I9c42d14eb6ebe14d249df7c8fa39e889f7cd3f22
Reviewed-on: https://go-review.googlesource.com/c/go/+/374754
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.
Fixes#50190.
Change-Id: I025ceb09a86e00b7583d3b9885d612f5d6cb44fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/372914
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The failure mode in #37794 does not match the failure mode described
in #18784. However, since the test is currently skipped on all other
MIPS variants, it may be that they suffer from the same underlying GDB
bug. Ideally one of the Go MIPS maintainers should file an upstream
bug and remove the skip once it is fixed; in the meantime, there is no
point in continuing to let the test fail on just one of the four MIPS
variants.
For #37794
Change-Id: I570f51cc04cbb7ef1ed7efd526e26886af53bfb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/376654
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Finally figured out how to deal with the interaction between generics
and inlining. The problem has been: what to do if you inline a function
that uses a new instantiated type that hasn't been seen in the current
package? This might mean that you need to do another round of
function/method instantiatiations after inlining, which might lead to
more inlining, etc. (which is what we currently do, but it's not clear
when you can stop the inlining/instantiation loop).
We had thought that one solution was to export instantiated types (even
if not marked as exportable) if they are referenced in exported
inlineable functions. But that was quite complex and required changing
the export format. But I realized that we really only need to make sure
the relevant dictionaries and shape instantiations for the instantiated
types are exported, not the instantiated type itself and its wrappers.
The instantiated type is naturally created as needed, and the wrappers
are generated automatically while writing out run-time type (making use
of the exported dictionaries and shape instantiations).
So, we just have to make sure that those dictionaries and shape
instantiations are exported, and then they will be available without any
extra round of instantiations after inlining. We now do this in
crawler.go. This is especially needed when the instantiated type is only
put in an interface, so relevant dictionaries/shape instantiations are
not directly referenced and therefore exported, but are still needed for
the itab.
This fix avoids the phase ordering problem where we might have to keep
creating new type instantiations and instantiated methods after each
round of inlining we do.
Removed the extra round of instantiation/inlining that were added in the
previous fix. The existing tests
test/typeparam{geninline.go,structinit.go} already test this situation
of inlining a function referencing a new instantiated type.
Added the original example from issue 50121 as test (has 5 packages),
since it found a problem with this code that the current simpler test
for 50121 did not find.
Change-Id: Iac5d0dddf4be19376f6de36ee20a83f0d8f213b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/375494
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Currently TestCPUProfileMultithreadMagnitude runs two CPU consumption
functions in a single profile and then analyzes the results as separate
subtests.
This works fine, but when debugging failures it makes manual analysis of
the profile dump a bit annoying.
Refactor the test to collect separate profiles for each subtest for
easier future analysis.
For #50097.
For #50232.
Change-Id: Ia1c8bb86aaaf652e64c5e660dcc2da47d2194c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/372800
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rhys Hiltner <rhys@justin.tv>
Reviewed-by: Bryan Mills <bcmills@google.com>
When an http.FileServer is given a path like file1/file2 where file1
exists but file2 does not, the proper HTTP status should be
NotFound. Some OSes return a "not a directory" error instead, so this
must be mapped to NotFound.
That mapping was already being done for the Dir FileSystem
implementation, as discussed in #18984. But it wasn't for the
FS implementation.
This CL does the same mapping for FS, by generalizing the function
that did it for Dir.
Fixes#49552
Change-Id: I61d6aa8ef101158e9674707d44e653f5dedbd040
Reviewed-on: https://go-review.googlesource.com/c/go/+/376874
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Upgrade the test certificate from RSA 1024 (not FIPS-approved)
to RSA 2048 (FIPS-approved), allowing tests to pass when
the dev.boringcrypto branch FIPS-only mode is enabled.
Fixes#48674.
Change-Id: I613d2f8d0207bf3683fd0df256bf0167604996c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353869
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The VDSO (__kernel_vsyscall) is reachable via
asmcgocall(cgo_start_thread) on linux-386, which causes traceback to
throw.
Fixes#49182.
For #50504.
Change-Id: Idb78cb8de752203ce0ed63c2dbd2d12847338688
Reviewed-on: https://go-review.googlesource.com/c/go/+/376656
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Similarly to what we do for the built-in function `copy`,
where we allow a string as 2nd argument to append, also
permit a type parameter constrained by string|[]byte.
While at it, change date in the manual.go2 test files so
that we don't need to constantly correct it when copying
a test case from that file into a proper test file.
Fixes#50281.
Change-Id: I23fed66736aa07bb3c481fe97313e828425ac448
Reviewed-on: https://go-review.googlesource.com/c/go/+/376214
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
ReadDirent returns only as many directory entries as will fit in the
buffer, and each entry is variable-length — so we have no guarantee in
general that a buffer of a given arbitrary size can hold even one
entry, let alone all ten entries expected by the test.
Instead, iterate calls to ReadDirent until one of the calls returns
zero entries and no error, indicating that the directory has been read
to completion.
Fixes#37323
Change-Id: I7f1cedde7666107256604e4ea1ac13c71f22151a
Reviewed-on: https://go-review.googlesource.com/c/go/+/376334
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
For #47694.
Change-Id: I00862f987a0ff9f71e0295ce4320e6f9a6a4332f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376414
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 352870 added extra phase for instantiation after inlining, to take
care of the new fully-instantiated types. However, when fetching inlined
body of these types's methods, we need to allow OADDR operations on
untyped expressions, the same as what main inlining phase does.
The problem does not show up, until CL 371554, which made the compiler
do not re-typecheck while importing, thus leaving a OXDOT node to be
marked as address taken when it's not safe to do that.
Fixes#50437
Change-Id: I20076b872182c520075a4f8b84230f5bcb05b341
Reviewed-on: https://go-review.googlesource.com/c/go/+/375574
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Since a SECURITY.md file is present in the main Go repository,
GitHub already shows a "Report a security vulnerability" link
in the issue template list. Remove the duplicate custom link.
Fixes#49962.
Change-Id: Ifdf7e93b76ebd9258d907aa9cb4915c0dbc4f93e
Reviewed-on: https://go-review.googlesource.com/c/go/+/376357
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Julie Qiu <julie@golang.org>
Problem pointed out on golang-nuts mailing list.
Change-Id: If1c9b22e1ed7b4ec7ebcaadc80fa450333e6856c
Reviewed-on: https://go-review.googlesource.com/c/go/+/375799
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The release notes explicitly refer to sections updated
for generics in the spec but then point to the old spec
which is very confusing for beta users.
For #47694
Change-Id: I5b555db3543cc32f088a8b267ec3f1195a52a812
Reviewed-on: https://go-review.googlesource.com/c/go/+/373174
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #50317.
Change-Id: I24ccf333c380283a36b573ef8fc3e7fcd71bd17f
Reviewed-on: https://go-review.googlesource.com/c/go/+/376215
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Rat maintains the invariant that x.b.neg is always false,
but Rat.Denom was writing x.b.neg = false itself too.
That makes Rat.Denom a writing operation, when it should
be a read-only operation. That in turn makes it unsafe to
use from multiple goroutines, which is highly unexpected.
Make it read-only and therefore race-free again.
Fixes#50473.
Change-Id: I97b87913954511e5200c0665d16b9ed63422e505
Reviewed-on: https://go-review.googlesource.com/c/go/+/375935
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Work-around for #50481: report an error for multiple
blank type parameters. It's always possible to use
non-blank names in those cases.
We expect to lift this restriction for 1.19.
For #50481.
Change-Id: Ifdd2d91340aac1da3387f7d80d46e44f5997c2a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/376058
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Move switch to enable method type parameters entirely
to the parser, by adding the mode AllowMethodTypeParams.
Ensure that the error messages are consistent.
Remove unnecessary code in the type checker.
Fixes#50317.
Change-Id: I4f3958722400bdb919efa4c494b85cf62f4002bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/376054
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The c.startParallel channel on the testContext is stuck
in t.Parallel() because c.running starts at 1 for the main
fuzz parent test, and is causing a deadlock because it is
never released. It would normally be released by tRunner,
but needs to instead be released by fRunner instead for fuzz
tests.
Fixes#50217
Change-Id: I2d010e9adddfd8e8321ff2f9dd2e43daf46c128f
Reviewed-on: https://go-review.googlesource.com/c/go/+/374054
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change implements field the access p.f where the type of p
is a type parameter with a structural constraint that is a struct
with a field f. This is only the fix for the type checker. The
compiler will need a separate CL.
This makes the behavior consistent with the fact that we can
write struct composite literals for type parameters with a
struct structural type.
For #50417.
For #50233.
Change-Id: I87d07e016f97cbf19c45cde19165eae3ec0bad2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/375795
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The underlying type of a type parameter is an interface,
so we don't need a special case for type parameters anymore.
Simply share the (identical) code for interfaces.
Adjust code in types.NewMethodSet accordingly.
No functional difference.
Preparation for fix of issues below.
For #50233.
For #50417.
Change-Id: Ib2deadd12f89e6918dec224b4ce35583001c3101
Reviewed-on: https://go-review.googlesource.com/c/go/+/375514
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>
Do this by running verification for instantiated signatures
later, after the delayed type parameter set-up had a chance
to wrap type bounds in implicit interfaces where needed.
Fixes#50450
Change-Id: If3ff7dc0be6af14af854830bfddb81112ac575cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/375737
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>
