This involved a couple non-trivial fixes in go/types:
- move the check for main function signature to resolver.go, to be
consistent with init. Also, update uses of _InvalidInitSig to
_InvalidInitDecl, consistent with what we decided for dev.regabi.
- Update some tests in api_test.go which newly fail after CL 289715
(fixing reporting of untyped nil) In all cases but one, these updates
were consistent with types2. However, in one case types2 seems to be
able to resolve more type information than go/types for a broken
package. I left a TODO to investigate this further.
Change-Id: I8244b7c81654194edd5af8de689a13c262117dff
This is a port of CL 284052 to go/types. The port is not entirely
faithful, as untyped conversion has been refactored in go/types.
Additionally, a comment was added to reference issue #13061 in the
implicitType method.
For #13061
Change-Id: Iec17611f6432c988624023d1d74121ff34eb0c83
Reviewed-on: https://go-review.googlesource.com/c/go/+/289715
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Disabled test/typeparam/fact.go for now as there's an issue
with stenciling.
Change-Id: Ie328a217de6d7b6695737f08ef5c944bcdaabd39
Reviewed-on: https://go-review.googlesource.com/c/go/+/290471
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
- Handle generic function calling itself or another generic function in
stenciling. This is easy - after it is created, just scan an
instantiated generic function for function instantiations (that may
needed to be stenciled), just like non-generic functions. The types
in the function instantiation will already have been set by the
stenciling.
- Handle OTYPE nodes in subster.node() (allows for generic type
conversions).
- Eliminated some duplicated work in subster.typ().
- Added new test case fact.go that tests a generic function calling
itself, and simple generic type conversions.
- Cause an error if a generic function is to be exported (which we
don't handle yet).
- Fixed some suggested changes in the add.go test case that I missed in
the last review.
Change-Id: I5d61704254c27962f358d5a3d2e0c62a5099f148
Reviewed-on: https://go-review.googlesource.com/c/go/+/290469
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Now that we have a g register, just use it.
Note: functions that can be called from ABI0 context (e.g.
morestack) is unchanged. Functions that switch g is also
unchanged, because we need to set the new g in both the register
and TLS.
TODO: other OSes.
Change-Id: I692a82a7caa8417ff620a59676a6275f56747b94
Reviewed-on: https://go-review.googlesource.com/c/go/+/289718
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In ABIInternal context, we can directly use the g register for
stack bounds check.
Change-Id: I8b1073a3343984a6cd76cf5734ddc4a8cd5dc73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/289711
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In case that we are panicking in ABI0 context or external code,
special registers are not initialized. Initialized them in
injected code before calling sigpanic.
TODO: Windows, Plan 9.
Change-Id: I0919b80e7cc55463f3dd94f1f63cba305717270a
Reviewed-on: https://go-review.googlesource.com/c/go/+/289710
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This is a proof-of-concept change for using the g register on
AMD64. getg is now lowered to R14 in the new ABI. The g register
is not yet used in all places where it can be used (e.g. stack
bounds check, runtime assembly code).
Change-Id: I10123ddf38e31782cf58bafcdff170aee0ff0d1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/289196
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
medianBucket can return if the total is greater than thresh.
However, if a histogram has no counts, total and thresh
will both be zero and cause panic.
Adding an equal sign to prevent the potential panic.
Fixes#44148
Change-Id: Ifb8a781990f490d142ae7c035b4e01d6a07ae04d
Reviewed-on: https://go-review.googlesource.com/c/go/+/290171
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change Plan 9 fork/exec to use the O_CLOEXEC file
descriptor, instead of relying on spooky at a
distance.
Historically, Plan 9 has set the O_CLOEXEC flag on
the underlying channels in the kernel, rather
than the file descriptors -- if two fds pointed
at a single channel, as with dup, changing the
flags on one of them would be observable on the
other.
The per-Chan semantics are ok, if unexpected,
when a chan is only handled within a single
process, but this isn't always the case.
Forked processes share Chans, but even more of
a problem is the interaction between /srv and
OCEXEC, which can lead to unexectedly closed
file descriptors in completely unrelated
proceses. For example:
func exists() bool {
// If some other thread execs here,
// we don't want to leak the fd, so
// open it O_CLOEXEC
fd := Open("/srv/foo", O_CLOEXEC)
if fd != -1 {
Close(fd)
return true
}
return false
}
would close the connection to any file descriptor
(maybe even for the root fs) in ALL other processes
that have it open if an exec were to happen(!),
which is quite undesriable.
As a result, 9front will be changing this behavior
for the next release.
Go is the only code observed so far that relies on
this behavior on purpose, and It's easy to make the
code work with both semantics: simply using the file
descriptor that was opened with O_CEXEC instead of
throwing it away.
So we do that here.
Fixes#43524
Change-Id: I4887f5c934a5e63e5e6c1bb59878a325abc928d3
GitHub-Last-Rev: 96bb21bd1e
GitHub-Pull-Request: golang/go#43533
Reviewed-on: https://go-review.googlesource.com/c/go/+/281833
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Richard Miller <millerresearch@gmail.com>
Reviewed-by: Jacob Moody <j4kem00dy@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
In shared build mode and linkage, currently we assume all
function symbols are ABI0 (except for generated type algorithm
functions), and alias them to ABIInternal. When the two ABIs
actually differ (as it is now), this is not actually correct.
This CL resolves symbol ABI based on their mangled names.
If the symbol's name has a ".abi0" or ".abiinternal" suffix, it
is of the corresponding ABI. The symbol without the suffix is
the other ABI. For functions without ABI wrapper generated,
only one ABI exists but we don't know what it is, so we still
use alias (for now).
Change-Id: I2165f149bc83d513e81eb1eb4ee95464335b0e75
Reviewed-on: https://go-review.googlesource.com/c/go/+/289289
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Add missed heading tag in CL 276373.
For #40700
Change-Id: Ida9e8861589bbc296a5a1cecbf9fe33fa09ed0ca
GitHub-Last-Rev: d218f8d4b7
GitHub-Pull-Request: golang/go#44111
Reviewed-on: https://go-review.googlesource.com/c/go/+/289869
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Tim King <taking@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Do not require directory entry and Stat result to match for symlinks,
because they won't (Stat dereferences the symlink).
Fixes#44113.
Change-Id: Ifc6dbce5719906e2f42254a7172f1ef787464a9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/290009
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The runtime.gosave function is not used anywhere. Delete.
Note: there is also a gosave<> function, which is actually used
and not deleted.
Change-Id: I64149a7afdd217de26d1e6396233f2becfad7153
Reviewed-on: https://go-review.googlesource.com/c/go/+/289719
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
racecall can be called in ABIInternal context (e.g. raceread
calling racecalladdr calling racecall) without wrapper. racecall
calls C code, which doesn't preserve our special registers. Set
them explicitly in racecall upon returning from C.
Change-Id: Ic990479c1fca6bb8a3b151325c7a89be8331a530
Reviewed-on: https://go-review.googlesource.com/c/go/+/289709
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Define g register as R14 on AMD64. It is not used now, but will
be in later CLs.
The name "R14" is still recognized.
Change-Id: I9a066b15bf1051113db8c6640605e350cea397b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/289195
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
racecallbackthunk is called from C, and it needs to follow C ABI.
The assembly code preserves C callee-save registers. It must not
be called via wrappers, which may not preserve those registers.
Change-Id: Icd72c399f4424d73c4882860d85057fe2671f6aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/289194
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
rt0_go is not actually ABIInternal, and it actually has callers
(e.g. _rt0_amd64).
Change-Id: Id730176e620ad9f443e6bfca6ded81a1367531ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/289193
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Allow full compilation and running of simple programs with generic
functions by stenciling on the fly the needed generic functions. Deal
with some simple derived types based on type params.
Include a few new typeparam tests min.go and add.go which involve
fully compiling and running simple generic code.
Change-Id: Ifc2a64ecacdbd860faaeee800e2ef49ffef9df5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/289630
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, when using cgo, the g pointer is set via a separate
call to setg_gcc or with inline assembly in threadentry. This CL
changes it to call setg_gcc in crosscall_amd64, like other g-
register platforms. When we have an actual g register on AMD64,
we'll need to set the register immediately before calling into
Go.
Change-Id: Ib1171e05cd0dabba3b7d12e072084d141051cf3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/289192
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Add respective check to type checker.
Remove respective check from the compiler's new type2-based noder.
Updates #31793.
Change-Id: I907e3acab4c136027a8c3db1e9bac301d209c2e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/289570
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This enables another test.
Change-Id: I80763b97d939e225158a083299b2e0d189268bc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/289569
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Add the Config.Lang field which may be set to a Go version string,
such as "go1.12". This is a string rather than explicit semantic
version numbers (such as {1, 12}) for API robustness; a string
is more flexible should we need more or different information.
Add -lang flag to types2 package for use with (manual) testing
when running "go test -run Check$ -lang=... -files=...".
While changing flags, look for comma-separated (rather than space-
separated) files when providing the -file flag.
Check that numeric constant literals, signed shift counts are
accepted according to the selected language version.
Type alias declarations and overlapping embedded interfaces are
not yet checked.
Updates #31793.
Change-Id: I9ff238ed38a88f377eb2267dc3e8816b89a40635
Reviewed-on: https://go-review.googlesource.com/c/go/+/289509
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This matches the compiler's existing limitations and thus ensures
that types2 reports the same errors for oversize integer constants.
Change-Id: I4fb7c83f3af69098d96f7b6c53dbe3eaf6ea9ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/288633
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a port of CL 279424, which didn't make it into master in time
for go1.16. Move it to dev.regabi so that it may be merged.
Notably, this port no longer removes the _InvalidInitSig error code,
instead opting to deprecate it. Now that error codes are 'locked in' for
go1.16, even if their API may not yet be exposed, we should follow the
practice of not changing their values. In the future, code generation
can make it easier to keep error code values constant.
For #43308
Change-Id: I5260b93fd063393d38d6458e45a67e7f9b7426ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/289714
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>
Symbol's Attributes and ABI are in the same word. In the
concurrent backend, we may read one symbol's ABI (the callee)
while setting its attributes in another goroutine.
Fix racecompile build.
Change-Id: I500e869bafdd72080119ab243db94eee3afcf926
Reviewed-on: https://go-review.googlesource.com/c/go/+/289290
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
On the dev.typeparams and dev.go2go branches, check_test.go has been
updated to automatically discover test data. This is convenient, so port
it to dev.regabi.
Change-Id: I5da9a9a5139c35a2693e64364eb9928ece1cd7c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/289713
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 is a port of CL 274615, adapted to go/types. The only change was in
the positioning of expected errors in vardecl.src: in go/types they are
positioned on the identifier.
Change-Id: Iab03265a7c4287749373e4380c6db6a95f262f30
Reviewed-on: https://go-review.googlesource.com/c/go/+/289712
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>
errors_test.go was missed during merging. Add it.
Change-Id: I321f08ae16ca02586875e1c7776f5d78f8690b4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/289549
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>
In ABIInternal, reserve X15 as constant zero, and use it to zero
memory. (Maybe there can be more use of it?)
The register is zeroed when transition to ABIInternal from ABI0.
Caveat: using X15 generates longer instructions than using X0.
Maybe we want to use X0?
Change-Id: I12d5ee92a01fc0b59dad4e5ab023ac71bc2a8b7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288093
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Mark the syscall wrappers as ABIInternal, as they have addresses
taken from Go code, and it is important to call to them without
wrappers.
Previously, the wrapper is just a single JMP instruction, which
makes it not matter. In the next CL we'll make the wrapper
actually have a frame. The real wrappers will mess up things
such as stack alignment for C ABI.
This doesn't look really nice, but I don't know how we can do
better...
TODO: other OSes.
Change-Id: Ifb3920494990a7775e3e6902fbcaf137df3cc653
Reviewed-on: https://go-review.googlesource.com/c/go/+/288092
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Change-Id: I6290bc4921ef17586b5028d3f40a88372b175014
Reviewed-on: https://go-review.googlesource.com/c/go/+/289269
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The compiler uses 512 bit of precision for untyped constant
arithmetic but didn't restrict the length of incoming constant
literals in any way, possibly opening the door for excessively
long constants that could bring compilation to a crawl.
Add a simple check that refuses excessively long constants.
Add test.
Change-Id: I797cb2a8e677b8da2864eb92d686d271ab8a004d
Reviewed-on: https://go-review.googlesource.com/c/go/+/289049
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>
These newly enabled (not anymore excluded) tests pass now
that we run in -G=3 mode when using the new types2 based
noder.
Change-Id: I5e7304c8020f394b79737d67c750bebbe02bd502
Reviewed-on: https://go-review.googlesource.com/c/go/+/289109
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
There appears to be a typo in the description of
the recursive division algorithm.
Two things seem suspicious with the original comment:
1. It is talking about choosing s, but s doesn't
appear anywhere in the equation.
2. The math in the equation is incorrect.
Where
B = len(v)/2
s = B - 1
Proof that it is incorrect:
len(v) - B >= B + 1
len(v) - len(v)/2 >= len(v)/2 + 1
This doesn't hold if len(v) is even, e.g. 10:
10 - 10/2 >= 10/2 + 1
10 - 5 >= 5 + 1
5 >= 6 // this is false
The new equation will be the following,
which will be mathematically correct:
len(v) - s >= B + 1
len(v) - (len(v)/2 - 1) >= len(v)/2 + 1
len(v) - len(v)/2 + 1 >= len(v)/2 + 1
len(v) - len(v)/2 >= len(v)/2
This holds if len(v) is even or odd.
e.g. 10
10 - 10/2 >= 10/2
10 - 5 >= 5
5 >= 5
e.g. 11
11 - 11/2 >= 11/2
11 - 5 >= 5
6 >= 5
Change-Id: If77ce09286cf7038637b5dfd0fb7d4f828023f56
Reviewed-on: https://go-review.googlesource.com/c/go/+/287372
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
The compiler chooses the literal value export format by type
not by constant.Kind. That is, a floating-point constant is
always exported as a (big) float value, not a (big) rational
value, even though the internal representation may be that
of a rational number. (This is a possibility now that the
compiler also uses the go/constant package.)
Naturally, during import, a floating-point value is read as
a float and represented as a (big) float in go/constant.
The types2 importer (based on the go/types importer) read
the floating-point number elements (mantissa, exponent) but
then constructed the float go/constant value through a series
of elementary operations, typically leading to a rational,
but sometimes even an integer number (e.g. for math.MaxFloat64).
There is no problem with that (the value is the same) but if
we want to impose bitsize limits on overlarge integer values
we quickly run into trouble with large floats represented as
integers.
This change matches the code importing float literals with
the code used by the compiler.
Note: At some point we may want to relax the import/export code
for constant values and export them by representation rather than
by type. As is, we lose accuracy since all floating-point point
values, even the ones internally represented as rational numbers
end up being exported as floating-point numbers.
Change-Id: Ic751b2046a0fd047f751da3d35cbef0a1b5fea3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/288632
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Create an extra OFUNCINST node as needed, if there are inferred type
arguments for a generic function call.
Change-Id: Id990c5bcbce2893377072a7e41c7c6785d1eab60
Reviewed-on: https://go-review.googlesource.com/c/go/+/288952
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Expresses things more clearly, especially in cases like 'f := min[int]'
where we create a xsgeneric function instantiation, but don't immediately
call it.
min[int](2, 3) now looks like:
. CALLFUNC tc(1) Use:1 int # min1.go:11 int
. . FUNCINST tc(1) FUNC-func(int, int) int # min1.go:11 FUNC-func(int, int) int
. . . NAME-main.min tc(1) Class:PFUNC Offset:0 Used FUNC-func[T](T, T) T # min1.go:3
. . FUNCINST-Targs
. . . TYPE .int Offset:0 type int
. CALLFUNC-Args
. . LITERAL-2 tc(1) int # min1.go:11
. . LITERAL-3 tc(1) int # min1.go:11
Remove the targs parameter from ir.NewCallExpr(), not needed anymore,
since type arguments are included in the FUNCINST.
Change-Id: I23438b75288330475294d7ace239ba64acfa641e
Reviewed-on: https://go-review.googlesource.com/c/go/+/288951
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Will now run "go tool compile -G=2 -W=2" on a simple generic function
with multiple type parameters and a call to that function with multiple
explicit type arguments.
We will likely move to have a separate function/type instantiation node,
in order distinguish these cases from normal index expressions.
Change-Id: I0a571902d63785cc06240ed4ba0495923403b511
Reviewed-on: https://go-review.googlesource.com/c/go/+/288433
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 example, var v, ok T1 = x.(T), can be interpreted as type T1 interface{} or type T = bool; type T1 = T.
Separating the example would help understanding for readers.
Change-Id: I179f4564e67f4d503815d29307df2cebb50c82f9
GitHub-Last-Rev: b34fffb6bb
GitHub-Pull-Request: golang/go#44040
Reviewed-on: https://go-review.googlesource.com/c/go/+/288472
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
In the linker's deadcode pass we decode type symbols for
interface satisfaction analysis. When linking against Go shared
libraries, the type symbol may come from a shared library, so it
doesn't have data in the current module being linked, so we cannot
decode it. We already have code to skip DYNIMPORT symbols. However,
this doesn't actually work, because at that point the type symbols'
names haven't been mangled, whereas they may be mangled in the
shared library. So the symbol definition (in shared library) and
reference (in current module) haven't been connected.
Skip decoding type symbols of type Sxxx (along with DYNIMPORT)
when linkShared.
Note: we cannot skip all type symbols, as we still need to mark
unexported methods defined in the current module.
Fixes#44031.
Change-Id: I833d19a060c94edbd6fc448172358f9a7d760657
Reviewed-on: https://go-review.googlesource.com/c/go/+/288496
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
We want to find a section that contains addr. sect.Addr+sect.Size
is the exclusive upper bound.
Change-Id: If2cd6bdd6e03174680e066189b0f4bf9e2ba6630
Reviewed-on: https://go-review.googlesource.com/c/go/+/288592
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Will now run "go tool compile -G=2 -W=2" on a simple generic function
with one type parameter and a call to that function with one explicit
type argument. Next change will handle multiple type arguments.
Change-Id: Ia7d17ea2a02bf99bd50e673ac80ae4aad4c48440
Reviewed-on: https://go-review.googlesource.com/c/go/+/288432
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
CL 279423 introduced a regression in this test as it incorrectly laid
out various instructions. In the case of arm, the second instruction
was overwriting the first. In the case of 386, amd64 and s390x, the
instructions were being appended to the end of the slice after 64
zero bytes.
This was causing test failures on "linux/s390x on z13".
Fixes#44028
Change-Id: Id136212dabdae27db7e91904b0df6a3a9d2f4af4
Reviewed-on: https://go-review.googlesource.com/c/go/+/288278
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add a test case for issue 43818. We don't want to mark as inlinable a
function with a closure that has an operation (such as OSELRECV2) that
we don't currently support for exporting. This test case fails to
compile without the fix for #43818.
Updates #43818
Change-Id: Ief322a14aefaefc6913c40a6b8505214bd622fda
Reviewed-on: https://go-review.googlesource.com/c/go/+/288392
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
