When being used by the compiler, augment the types2 missing method
message with extra info, if a method is missing, but a method with the
correct name except for case (i.e. equal via string.EqualFold()) is
present. In that case, print out the wanted method and the method that
is present (that has the wrong case).
In the 1.17 compiler, we don't do this case-folding check when assigning
an interface to an interface, so I didn't add that check, but we could
add that.
Fixes#48471
Change-Id: Ic54549c1f66297c9221d979d49c1daa719aa66cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/363437
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When being used by the compiler, fix up types2 error messages to be more
like Go 1.17 compiler errors. In particular:
- add information about which method is missing when a type is not
assignable/convertible/etc. to an interface.
- add information about any existing method which has the same name,
but wrong type.
- add extra hint in the case that the source or destination type is a
pointer to an interface, rather than an interface.
- add extra hint "need type assertion" in the case that the source is
an interface that is implemented by the destination.
- the following change in the CL stack also adds information about any
existing method with a different name that only differs in case.
Include much of the new logic in a new common function
(*Checker).missingMethodReason().
types2 still adds a little more information in some cases then the Go
1.17 compiler. For example, it typically says "(value of type T)",
rather than "(type T)", where "value" could also be "constant",
"variable", etc.
I kept the types2 error messages almost all the same when types2 is not
used by the compiler. The only change (to reduce amount of compatibility
code) was to change "M method" phrasing in one case to "method M"
phrasing in one error message (which is the phrasing it uses in all
other cases). That is the reason that there are a few small changes in
types2/testdata/check/*.src.
Added new test test/fixedbugs/issue48471.go to test that the added
information is appearing correctly.
Also adjusted the pattern matching in a bunch of other
test/fixedbugs/*.go, now that types2 is producing error messages closer
to Go 1.17. Was able to remove a couple test files from the types2
exception list in run.go.
Updated #48471
Change-Id: I8af1eae6eb8a5541d8ea20b66f494e2e795e1956
Reviewed-on: https://go-review.googlesource.com/c/go/+/363436
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Like OFUNCINST, in case of OXDOT call expression, the arguments need
to be transformed earlier, so any needed CONVIFACE nodes are exposed.
Fixes#49538
Change-Id: I275ddf6f53a9cadc8708e805941cdf7bdffabba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/363554
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Currently the recover4 test, which recovers from a panic created from a
fault, generates a fault by creating a hole in a mapping. It does this
via munmap. However, it's possible the runtime can create a new mapping
that ends up in that hole, for example if the GC executes, causing the
test to fail.
In fact, this is the case now with a smaller minimum heap size.
Modify the test to use mprotect, and clean up the code a little while
we're here: define everything in terms of the length of original
mapping, deduplicate some constants and expressions, and have the test
recover properly even if recover() returns nil (right now it panics
because it fails to type assert nil as error).
Fixes#49381.
Change-Id: If399eca564466e5e8aeb2dc6f86a246d0fce7b5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/363534
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Our compiler gets confused between functions that were declared
with no body, and those which have a body but it is empty.
Ensure that when stenciling, we generate a nonempty body.
The particular test that causes this problem is in
cmd/compile/internal/gc/main.go:enqueueFunc. It thinks that if
a function has no body, then we need to generate ABI wrappers for
it, but not compile it.
Fixes#49524
Change-Id: Id962666a2098f60a2421484b6a776eafdc4f4a63
Reviewed-on: https://go-review.googlesource.com/c/go/+/363395
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>
When building a call expression for function instantiation closure, if
it's a variadic function, the CallExpr.IsDDD must be set for typecheck
to work properly. Otherwise, there will be a mismatch between the
arguments type and the function signature.
Fixes#49516
Change-Id: I0af90ee3fcc3e6c8bba8b20e331e044cbce17985
Reviewed-on: https://go-review.googlesource.com/c/go/+/363314
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>
For #49512
Change-Id: Ic08652a4ec611b27150bf10b1118c1395715e5d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/363156
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For generic functions, we can export untransformed OKEY nodes, and the
key identifier is written as an ONONAME. But in this case, we do not
want to call Resolve() on the identifier, since we may resolve to a
global type (as happens in this issue) or other global symbol with the
same name, if it exists. We just want to keep the key identifier as an
Ident node.
To solve this, I added an extra bool when exporting an ONONAME entry,
which indicates if this entry is for a key or for a global (external)
symbol. When the bool is true (this is for a key), we avoid calling
Resolve().
Fixes#49497
Change-Id: Ic8fa93d37bcad2110e0e0d060080b733e07e35d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/363074
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>
If we reach a generic type that is part of a cycle
and we are in a type parameter list, we have a cycle
through a type parameter list, which is invalid.
Fixes#49439.
Change-Id: Ia6cf97e1748ca0c0e61c02841202050091365b0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/361922
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When bulding formal arguments of newly created closure, irgen forgets to
set "..." field attribute, causing type mismatched between the closure
function and the ONAME node represents that closure function.
Fixes#49432
Change-Id: Ieddaa64980cdd3d8cea236a5a9de0204ee21ee39
Reviewed-on: https://go-review.googlesource.com/c/go/+/361961
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
CL 361411 improved error message for go version requirement, but forgot
to update the test in cmd/go to match new error message. That causes
longtest builders failed.
This CL changes mod_vendor_goversion.txt to match compiler error, and
limit fixedbugs/issue49368.go to run with -G=3 only.
Updates #49368
Change-Id: I125fe0a8c2a1595066d39c03e97819e7a1274e0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361963
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: Robert Findley <rfindley@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The openDeferRecord always insert vardef/varlive pairs into the entry block, it may destroy the mem chain when LECall's args are writing into the same block. So create a new block before that happens.
Fixes#49282
Change-Id: Ibda6c4a45d960dd412a641f5e02276f663c80785
Reviewed-on: https://go-review.googlesource.com/c/go/+/361410
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
CL 360057 fixed missing update source type in storeArgOrLoad. However,
we should only update the type when processing struct/array. If we
update the type right before calling storeArgOrLoad, we may generate a
value with invalid type, e.g, OpStructSelect with non-struct type.
Fixes#49378
Change-Id: Ib7e10f72f818880f550aae5c9f653db463ce29b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361594
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: David Chase <drchase@google.com>
This adds a debugging hook for optionally calling a "maymorestack"
function in the prologue of any function that might call morestack
(whether it does at run time or not). The maymorestack function will
let us improve lock checking and add debugging modes that stress
function preemption and stack growth.
Passes toolstash-check -all (except on js/wasm, where toolstash
appears to be broken)
Fixes#48297.
Change-Id: I27197947482b329af75dafb9971fc0d3a52eaf31
Reviewed-on: https://go-review.googlesource.com/c/go/+/359795
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Adjust TypeDefn(), which is used by reportTypeLoop(), to work for nodes
with no Ntype set (which are all nodes in -G=3 mode). Normally,
reportTypeLoop() would not be called, because the types2 typechecker
would have already caught it. This is a possible way to report an
unusual type loop involving type params, which is not being caught by
the types2 type checker.
Updates #48962
Change-Id: I55edee46026eece2e8647c5b5b4d8dfb39eeb5f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/361398
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Don't inline a function fn that has no shape parameters, but is passed
at least one shape arg. This means we must be inlining a non-generic
function fn that was passed into a generic function, and can be called
with a shape arg because it matches an appropriate type parameter. But
fn may include an interface conversion (that may be applied to a shape
arg) that was not apparent when we first created the instantiation of
the generic function. We can't handle this if we actually do the
inlining, since we want to know all interface conversions immediately
after stenciling. So, we avoid inlining in this case.
Fixes#49309.
Change-Id: I7b8ab7b13e58fdb0111db91bc92a91d313f7c2c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/361260
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>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After removing trivial wrapper types, the source needs to be updated
with new type, otherwise, it leads to mismatch between field offset and
the source type for selecting struct/array.
Fixes#49249
Change-Id: I26f9440bcb2e78bcf0617afc21d9d40cdbe4aca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/360057
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: David Chase <drchase@google.com>
Pointers to arrays can be used to cast from a slice. We need
the shape of such type params to be different so we can compile
those casts correctly.
This is kind of a big hammer to fix#49295. It would be nice to
only do this when we know there's a []T->*[N]T conversion.
Fixes#49295
Change-Id: Ibda33057fab2dd28162537aab0f1244211d68e3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/361135
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>
Add test for indexing on variables whose types are constrained to
various kinds of types.
Change-Id: I991eecfe39dba5d817c0fbe259ba558d4881ea84
Reviewed-on: https://go-review.googlesource.com/c/go/+/360867
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The types of the two interfaces should be equal, but they aren't.
We end up with multiple descriptors for a type when we need type
descriptors to be unique.
Fixes#49241
Change-Id: I8a6c70da541c6088a92a01392bc83b61cc130eba
Reviewed-on: https://go-review.googlesource.com/c/go/+/360134
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When seeing Key:Value expression in slice literal, the compiler only
needs to emit tmp var for the Value, not the whole expression.
Fixes#49240
Change-Id: I7bda3c796a93c0fa1974f7c5930f38025dfa665c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360055
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: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In case of reference to method call of an imported fully-instantiated
type, nameNode.Func will be nil causes checkFetchBody panic. To fix
this, make sure checkFetchBody is only called when Func is not nil.
Fixes#49246
Change-Id: I32e9208385a86d4600d8ebf6f5efd8fca571ea16
Reviewed-on: https://go-review.googlesource.com/c/go/+/360056
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Updated multiple tests in test/codegen/arithmetic.go to verify
on ppc64/ppc64le as well
Change-Id: I79ca9f87017ea31147a4ba16f5d42ba0fcae64e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/358546
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, the compiler will emit any const that doesn't fit in an
int64 to go_asm.h like
#define const_stackPreempt constant.intVal{val:(*big.Int)(0xc000c06c40)}
This happens because dumpasmhdr formats the constant.Value using the
verb "%#v". Since constant.Value doesn't implement the GoString()
method, this just prints the Go-syntax representation of the value.
This happens to work for small integer constants, which go/constant
represents directly as an int64, but not for integer constants that
don't fit in an int64, which go/constant represents as a big.Int.
Make these constants usable by changing the formatting verb to "%v",
which will call the String() method, giving a reasonable result in all
cases.
Change-Id: I365eeb88c8acfc43ff377cc873432269bde3f541
Reviewed-on: https://go-review.googlesource.com/c/go/+/359954
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Use types2.Structure() to get single underlying type of typeparams, to
handle some unusual cases where a type param is constrained to a single
underlying struct or map type.
Fixes#48538
Change-Id: I289fb7b31d489f7586f2b04aeb1df74e15a9f965
Reviewed-on: https://go-review.googlesource.com/c/go/+/359335
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fix two defer bugs related to adding/removing open defer entries.
The bugs relate to the way that we add and remove open defer entries
from the defer chain. At the point of a panic, when we want to start
processing defer entries in order during the panic process, we need to
add entries to the defer chain for stack frames with open defers, since
the normal fast-defer code does not add these entries. We do this by
calling addOneOpenDeferFrame() at the beginning of each time around the
defer loop in gopanic(). Those defer entries get sorted with other open
and non-open-coded defer frames.
However, the tricky part is that we also need to remove defer entries if
they end not being needed because of a recover (which means we are back
to executing the defer code inline at function exits). But we need
to deal with multiple panics and in-process defers on the stack, so we
can't just remove all open-coded defers from the the defer chain during
a recover.
The fix (and new invariant) is that we should not add any open-coded
defers to the defer chain that are higher up the stack than an open-coded
defer that is in progress. We know that open-coded defer will still be
run until completed, and when it is completed, then a more outer frame
will be added (if there is one). This fits with existing code in gopanic
that only removes open-coded defer entries up to any defer in progress.
These bugs were because of the previous inconsistency between adding and
removing open defer entries, which meant that stale defer entries could
be left on the list, in these unusual cases with both recursive
panics plus multiple independent (non-nested) cases of panic & recover.
The test for #48898 was difficult to add to defer_test.go (while keeping
the failure mode), so I added as a go/test/fixedbug test instead.
Fixes#43920
Updates #43941Fixes#48898
Change-Id: I593b77033e08c33094315abf8089fbc4cab07376
Reviewed-on: https://go-review.googlesource.com/c/go/+/356011
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
We may revisit this decision in a future release. By disallowing this
for Go 1.18 we are ensuring that we don't lock in the generics design
in a place that may need to change later. (Type declarations are the
primary construct where it crucially matters what the underlying type
of a type parameter is.)
Comment out all tests that rely on this feature; add comments referring
to issue so we can find all places easily should we change our minds.
Fixes#45639.
Change-Id: I730510e4da66d3716d455a9071c7778a1e4a1152
Reviewed-on: https://go-review.googlesource.com/c/go/+/359177
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Now that we permit arbitrary types as constraints, we no longer need them.
For #48424
Change-Id: I15fef26a563988074650cb0801895b002c44148a
Reviewed-on: https://go-review.googlesource.com/c/go/+/359258
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes#49110
Change-Id: I32c2cb26cca067a4a676ce4bbc3e51f1e0cdb259
Reviewed-on: https://go-review.googlesource.com/c/go/+/357959
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Sebastien Binet <s@sbinet.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For base generic type that is written to export file, we need to mark
all of its methods, include exported+unexported methods, as reachable,
so they can be available for instantiation if necessary. But markType
only looks for exported methods, thus causing the crash in #49143.
To fix this, we introduce new method p.markGeneric, to mark all methods
of the base generic type.
This issue has happend for a while (maybe since we add generic
import/export during go1.18 cycle), and was un-intentionally "fixed" in
CL 356254, when we agresssively call p.markEmbed(t). CL 357232 fixed
that wrong agressive behavior, thus reproduce the bug on tip.
Fixes#49143
Change-Id: Ie64574a05fffb282e9dcc8739df4378c5b6b0468
Reviewed-on: https://go-review.googlesource.com/c/go/+/358814
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.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: Dan Scales <danscales@google.com>
There were two main outer switch statements in node() that can just be
combined. Also, for simplicity, changed an IsCmp() conditional into just
another case in the switch statement.
Also, the inner OCALL switch statement had a bunch of fairly duplicate
cases. Combined the cases that all had no special semantics, into a
single default case calling transformCall().
In the OCALL case in dictPass(), got rid of a check for OFUNCINST (which
will always have been removed by this point). Also, eliminated an assert
that could cause unneded failures. transformCall() should always be
called if the node op is still OCALL, so no need to assert on the ops of
call.X.
Added an extra test in issue47078.go, to explicitly check for case where
the X argument of a call is a DOTTYPE.
Change-Id: Ifb3f812ce12820a4ce08afe2887f00f7fc00cd2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/358596
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>
To capture the fact that a method was called on a generic interface,
so we can make sure the linker doesn't throw away any implementations
that might be the method called.
See the comment in reflect.go for details.
Fixes#49049
Change-Id: I0be74b6e727c1ecefedae072b149f59d539dc1e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/357835
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: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CL 357649 fixes inlining labeled FOR/RANGE loops,
we should do same translation for inlined SWITCH's label
Fixes#49145
Change-Id: I9a6f365f57e974271a1eb279b38e81f9b5148788
Reviewed-on: https://go-review.googlesource.com/c/go/+/358315
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.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: Dan Scales <danscales@google.com>
removePred and removeArg do different things. removePred moves the last
predecessor to index k, whereas removeArg slides all the args k or
greater down by 1 index.
Kind of unfortunate different behavior in things named similarly.
Fixes#49122
Change-Id: I9ae409bdac744e713f4c121f948e43db6fdc8542
Reviewed-on: https://go-review.googlesource.com/c/go/+/358117
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Since CL 282892, functions are always compiled before closures. To do
that, when walking the closure, it is added to its outer function queue
for scheduling compilation later. Thus, a closure may be added to queue
more than once, causing the ICE dues to being compiled twice.
To fix this, catching the re-walking of the closure expression and do
not add it to the compilation queue.
Fixes#49029
Change-Id: I7d188e8f5b4d5c4248a0d8e6389da26f1084e464
Reviewed-on: https://go-review.googlesource.com/c/go/+/357960
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>
CL 356254 fixed crawling of embeddable types during inline. However, we
are too agressive, since when we call markEmbed for every type seen
during inlining function body. That leads to false positive that for a
non-embedded type, its unexported methods are also marked inline.
Instead, we should only look at struct type that we seen during inlining
function body, and calling markEmbed for all of its embedded fields.
Fixes#49094
Change-Id: I6ef9a8bf1fc649ec6bf75e4883f6031ec8560ba1
Reviewed-on: https://go-review.googlesource.com/c/go/+/357232
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>
There is already a mechanism using inlgen to rename labels insided
inlined functions so that they are unique and don't clash with loops in
the outer function. This is used for OLABEL and OGOTO. Now that we are
doing inlining of OFOR loops, we need to do this translation for OBREAK,
OCONTINUE, and OFOR. I also added the translation for ORANGE loops, in
anticipation of a CL that will allow inlining of ORANGE for loops.
Fixes#49100
Change-Id: I2ccddc3350370825c386965f4a1e4bc54d3c369b
Reviewed-on: https://go-review.googlesource.com/c/go/+/357649
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
In CL 327872, there's a fix for crawling of embeddable types directly
reached by the user, so all of its methods need to be re-exported. But
we missed the cased when an un-exported type may be reachable by
embedding in exported type. Example:
type t struct {}
func (t) M() {}
func F() interface{} { return struct{ t }{} }
We generate the wrapper for "struct{ t }".M, and when inlining call to
"struct{ t }".M makes "t.M" reachable.
It works well, and only be revealed in CL 327871, when we changed
methodWrapper to always call inline.InlineCalls, thus causes the crash
in #49016, which involve dot type in inlined function.
Fixes#49016
Change-Id: If174fa5575132da5cf60e4bd052f7011c4e76c5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/356254
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>
Change-Id: I2fca7a801c85ed93c002c23bfcb0cf9593f1bdf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/356571
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>
This CL addresses the 2nd part of the issue below.
- For types2, now use the same error messages as the compiler in this case.
- Make the mechanism for reporting clarifying error messages handle the case
where we don't have additional position information.
- Provide context information (type assertion vs type switch).
Fixes#49005.
Change-Id: I4eeaf4f0c3f2f8735b63993778f58d713fef21ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/356512
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Findley <rfindley@google.com>
In CL 354670, I copied some existing rules for convenience but forgot
to update the last rule which broke `GOAMD64=v3 ./make.bat`
Revive CL 354670
Change-Id: Ic1e2047c603f0122482a4b293ce1ef74d806c019
Reviewed-on: https://go-review.googlesource.com/c/go/+/356810
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
