This way, "go version" will report the "base version" or major version
that the tool corresponds to. This is the same version number that is
matched against build tags such as "go1.14" or "!go1.16".
Obtaining this version being built is non-trivial, since we can't just
import a package or query git. The added comments document the chosen
mechanism, based on a regular expression. It was chosen over AST parsing
as it would add a significant amount of code without much gain, given
how simple the goversion.go file is.
For #41116.
Change-Id: I653ae935e27c13267f23898f89c84020dcd6e194
Reviewed-on: https://go-review.googlesource.com/c/go/+/264938
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The changes between (equivalent, and reviewed) go/types/errors.go
and errors.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The go/types version is significantly different as it handles
error codes but doesn't have some of the types2 changes.
Change-Id: I48f79ce31490db938c830df7d38e247d55d54f2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305577
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/stmt.go
and stmt.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker, and minor adjustments
to get the code slightly closer to go/types/stmt.go.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package, with significant
differences in the representation of switch and select statements,
range clauses of for statements, and inc/dec statements.
- no reporting of error codes
- use or error_ for collecting addition error information
Change-Id: I4409f62ecafd0653e4c8ef087c2580d8f0544efc
Reviewed-on: https://go-review.googlesource.com/c/go/+/305576
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/check_test.go
and check_test.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker, and minor adjustments
to get the code slightly closer to go/types/check_test.go.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package
- re-implemented mechanism for error matching and elimination
based on the syntax.ErrorMap mechanism (there's no exported
access to the syntax scanner)
- error matching permits for column tolerances because types2
column information doesn't match go/types column information
Change-Id: I8ae6bc93dfa2b517673b642064a1f09166755286
Reviewed-on: https://go-review.googlesource.com/c/go/+/305573
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>
The changes between (equivalent, and reviewed) go/types/resolver.go
and resolver.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package
- not using a walkDecl abstraction for const/var/type declarations
Change-Id: Id8d7b069813149ca4eadbb61d1124b22c56a91b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/305572
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>
There are a few remaining places in obj6 where we hard-code
safe-on-entry registers. Fix those to use the consts.
For #40724.
Change-Id: Ie640521aa67d6c99bc057553dc122160049c6edc
Reviewed-on: https://go-review.googlesource.com/c/go/+/307009
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change-Id: I2ed394fccec83aac09a49673554cbf504787965b
Reviewed-on: https://go-review.googlesource.com/c/go/+/306810
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Internally the compiler uses a0,a1,a3 string, not [3]string,
and this lead to different parameter passing (memory, versus registers)
which of course did not work.
Updates #40724.
Change-Id: I1dbf479b88134559ba54b4b00a042b9a0fd128b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/306910
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Fixes a mistake from golang.org/cl/298670.
Change-Id: I2f789f9fe003c856a993f7d462a2e84936743a1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/306930
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change removes two short-circuits for zero-sized types (zero-sized
structs and zero-sized struct fields) in the recursive cases of the ABI
algorithm, because this does not match the spec's algorithm, nor the
compiler's algorithm.
The failing case here is a struct with a field that is an array of
non-zero length but whose element type is zero-sized. This struct must
be stack-assigned because of the array, according to the algorithm.
The reflect package was register-assigning it.
Because there were two short-circuits, this can also appear if a struct
has a field that is a zero-sized struct but contains such an array,
also.
This change adds regression tests for both of these cases.
For #44816.
For #40724.
Change-Id: I956804170962448197a1c9853826e3436fc8b1ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/306929
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Leftover values that have been replaced can cause problems in later
passes (within expandCalls). For example, a struct select that
itself yields a struct will have a problematic rewrite, if the chance
is presented.
Updates #40724.
Change-Id: I1b445c47c301c3705f7fc0a9d39f1f5c84f4e190
Reviewed-on: https://go-review.googlesource.com/c/go/+/306869
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This change finishes off functionality register ABI for the reflect
package.
Specifically, it implements a call on a MakeFunc'd value by performing
the reverse process that reflect.Value.Call does, using the same ABI
steps. It implements a call on a method value created by reflect by
translating between the method value's ABI to the method's ABI.
Tests are added for both cases.
For #40724.
Change-Id: I302820b61fc0a8f94c5525a002bc02776aef41af
Reviewed-on: https://go-review.googlesource.com/c/go/+/298670
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
cgo_unsafe_args paragma indicates that the function (or its
callee) uses address and offsets to dispatch arguments, which
currently using ABI0 frame layout. Pin them to ABI0.
With this, "GOEXPERIMENT=regabi,regabiargs go run hello.go" works
on Darwin/AMD64.
Change-Id: I3eadd5a3646a9de8fa681fa0a7f46e7cdc217d24
Reviewed-on: https://go-review.googlesource.com/c/go/+/306609
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
asm_windows.s contains dummy references of syscall.loadlibrary
and syscall.getprocaddress, to trigger ABI wrapper/alias
generation to get ABI0 symbols for them. The comment says they
are called from assembly in other packages, but I couldn't find
where. They are defined in Go and only referenced in Go.
CL 179862 removed dummy references in the runtime. This CL
is similar, for the syscall package.
Also, with CL 306609, they will have ABI0 definitions anyway.
Change-Id: I5c7b0efb9762e4ad9c94f0beea8d053d8c8b2cd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306709
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
"internal/abi" package depends on runtime package and are supposed to
compile with "-+" option.Added internal/abi in the known list of package
that runtime depends on,so that "internal/abi" compiles with "-+".
Fixes#45144
Change-Id: Iad9e2589f2fbd014260cb8ef9f943d2126015fe1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306289
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It is never used. It is actually CompilationUnit.Lib.Pkg that
contains the package path.
Change-Id: I18189644ea080080868d144e81dfee02f4549133
Reviewed-on: https://go-review.googlesource.com/c/go/+/306710
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>
Remove a no-longer-used function.
Change-Id: Iad383a9d158d31d4c8b65dd39b71849b44c6b52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306829
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The math to invert the input index was wrong.
Fixes#45323
Change-Id: I7c68cac280e8f01a9c806ecb0f195f169267437e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306431
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, gcTestMoveStackOnNextCall doubles the stack allocation on
each call because stack movement always doubles the stack. That's
rather unfortunate if you're doing a bunch of stack movement tests in
a row that don't actually have to grow the stack because you'll
quickly hit the stack size limit even though you're hardly using any
of the stack.
Fix this by adding a special stack poison value for
gcTestMoveStackOnNextCall that newstack recognizes and inhibits the
allocation doubling.
Change-Id: Iace7055a0f33cb48dc97b8f4b46e45304bee832c
Reviewed-on: https://go-review.googlesource.com/c/go/+/306672
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gcTestMoveStackOnNextCall can fail to move the stack in very rare
cases if there's an unfortunately timed preemption that clobbers the
stack guard. This won't happen multiple times in quick succession, so
make the test just retry a few times.
Change-Id: I247dc0551514e269e7132cee7945291429b0e865
Reviewed-on: https://go-review.googlesource.com/c/go/+/306671
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 305672 we preserve the pointer type of a store by just not
decomposing it. But this can be problematic when the source of
the store is a direct interface aggregate type (e.g.
struct { x map[int]int }.
In this CL we take a different approach: we preserve the store
type when generating the new store, but also decompose the source.
Fixes#45344.
Change-Id: If5dd496458dee95aa649c6d106b96a6cdcf3e60d
Reviewed-on: https://go-review.googlesource.com/c/go/+/306669
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>
This change causes finalizers, reflect calls, and Windows syscall
callbacks to assume the register ABI when GOEXPERIMENT=regabiargs is
set. That is, when all Go functions are using the new ABI by default,
these features should assume the new ABI too.
For #40724.
Change-Id: Ie4ee66b8085b692e1ff675f01134c9a4703ae1b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/306571
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently when register assignment fails we roll back all the abiParts
that were generated in the process. However, the total number of
registers also increases, but does not get rolled back. The result is
a very incorrect register assignment.
For #40724.
For #44816.
Change-Id: I1934ea5f95f7608ff2067166255099dbc9135e8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/306109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Includes test.
Long term, need to make the offending code be more in terms
of official types package offsets, instead of duplicating that
logic.
For #40724.
Change-Id: Id33a153f10aed3289cc48d1f99a8e0f6ece9474d
Reviewed-on: https://go-review.googlesource.com/c/go/+/306469
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For struct like { { a int64; b int16 }; c int32 }, on 64-bit
machines the offset of c is 16, as the inner struct takes 16
bytes because we round up type size to its alignment. Update the
abi package's offset calculation to include this.
We only need to do this for struct type, because for all other
types its size is naturally aligned.
TODO: add a test.
Change-Id: I0c661768cb1ed3cb409b20a88b7e23e059f8e3e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306449
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>
The covers three kinds of uses:
1. Calls of closures from assembly. These are always ABIInternal calls
without wrappers. I went through every indirect call in the runtime
and I think mcall is the only case of assembly calling a Go closure in
a way that's affected by ABIInternal. systemstack also calls a
closure, but it takes no arguments.
2. Calls of Go functions that expect raw ABIInternal pointers. I also
only found one of these: callbackasm1 -> cgocallback on Windows. These
are trickier to find, though.
3. Finally, I found one case on NetBSD where new OS threads were
directly calling the Go runtime entry-point from assembly via a PC,
rather than going through a wrapper. This meant new threads may not
have special registers set up. In this case, a change on all other
OSes had already forced new thread entry to go through an ABI wrapper,
so I just caught NetBSD up with that change.
With this change, I'm able to run a "hello world" with
GOEXPERIMENT=regabi,regabiargs.
For #40724.
Change-Id: I2a6d0e530c4fd4edf13484d923891c6160d683aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/305669
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The logic for constructing calls in (*state).call is based around
targeted experiments with register-based calls. However, when the
register ABI is turned on everywhere, it currently doesn't account for
direct calls to non-ABIInternal functions. This CL adds a much simpler
path to (*state).call when regabiargs is turned on that looks at the
ABI of the target function.
For #40724.
Change-Id: I7f4f5fed8a5ec131bcf1ce5b9d94d45672a304cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/306410
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When regabiargs is enabled, a function's incoming ABI should be
determined solely by the function's own definition ABI (which is
usually ABIInternal, but can be ABI0 for ABI wrappers).
For example, the current code miscompiles ABI0 -> ABIInternal wrappers
when the experiment is enabled because it treats the wrapper itself as
being called as ABIInternal. This causes it to assume the incoming
arguments are already in registers, so usually the wrapper doesn't do
anything with the arguments because it thinks they're already in the
right place. With this fix, these wrappers now correctly load the
arguments from the stack and put them in registers.
For #40724.
Change-Id: Iec784e88ebc55d9e95e830ed7533aa336f3b1ca2
Reviewed-on: https://go-review.googlesource.com/c/go/+/306409
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently the prologue generated for WRAPPER assembly functions uses BX
and DI, but these are argument registers in the register-based calling
convention. Thus, these end up being clobbered when we want to have an
ABIInternal assembly function.
Define REGENTRYTMP0 and REGENTRYTMP1, aliases for the dedicated function
entry scratch registers R12 and R13, and use those instead.
For #40724.
Change-Id: Ica78c4ccc67a757359900a66b56ef28c83d88b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303314
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For in-register arguments, it must have only a single copy of it
present in the function. If there are multiple copies, it confuses
the register allocator, as they are in the same register.
Change-Id: I55cb06746f08aa7c9168026d0f411bce0a9f93f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/306330
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>
Coupling object resolution to parsing complicates the parsing code, and
is a barrier to improvement. It requires passing around context such as
'lhs' or 'keyOk', and even then sometimes requires guess-work, such as
whether to resolve the key in a composite literal.
In this CL we delay object resolution to a separate pass after the file
parse completes. This makes it easier to see logic of scoping, and
removes state from the parsing code. This can enable subsequent
improvements such as optionally skipping object resolution, aligning the
parser with cmd/compile/internal/syntax, and allowing alternative
parsers to reuse object resolution.
The additional AST traversal appears to slow down parsing by around 4%.
That seems small enough not to worry about, especially since performance
sensitive users may eventually be able to disable object resolution
entirely, saving around 18% off the previous baseline. I'll also mail a
speculative CL showing how we can significantly mitigate the cost of
object resolution by transposing scopes.
For #45104
Change-Id: I98d9143fd77ae29e84ec7c3ae2fdb1139510da37
Reviewed-on: https://go-review.googlesource.com/c/go/+/304455
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This change modifies the system that allows Go functions to be set as
callbacks in various Windows systems to support the new register ABI.
For #40724.
Change-Id: Ie067f9e8a76c96d56177d7aa88f89cbe7223e12e
Reviewed-on: https://go-review.googlesource.com/c/go/+/300113
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
OpArgXXXReg values must be scheduled at the very top, as their
registers need to be live at the beginning before any other use
of the register.
Change-Id: Ic76768bb74da402adbe61db3b2d174ecd3f9fffc
Reviewed-on: https://go-review.googlesource.com/c/go/+/306329
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>
The existing implementation implicitly reads from the filesystem
instead of using the overlay file data (due to src == nil), so
pass in the overlaid source if we have an overlay for this file.
Fixes#44946
Change-Id: I61ce09d10c5edac1b47332583efdcd3c1241f58a
Reviewed-on: https://go-review.googlesource.com/c/go/+/305071
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is accomplished by checking for simple stores of pointer types
and leaving them alone. The failure case was when a *mspan
(not in heap) stored type was replaced by unsafe.Pointer.
Updates #40724.
Change-Id: I529e1705bf58fb0e64e60d48fd550b3a407e57e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/305672
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With GOEXPERIMENT=regabidefer, all deferred functions take no
arguments and have no results (their signature is always func()).
Since the signature is fixed, we can replace all of the reflectcalls
in the defer code with direct closure calls.
For #40724.
Change-Id: I3acd6742fe665610608a004c675f473b9d0e65ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/306010
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The changes between (equivalent, and reviewed) go/types/operand.go
and operand.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package
- explicit mode for untyped nil (rather than relying on the type)
Change-Id: I0c9c1c6153c55cb0550096bd966c9f0f1c766734
Reviewed-on: https://go-review.googlesource.com/c/go/+/305571
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/decl.go
and decl.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker and a minor comment
update.
The primary differences to go/types/decl.go are:
- use of syntax rather than go/ast package
- use of error_ objects to collect follow-on error info
- use of check.conf.Trace rather than global trace flag
- more aggressively marking variables as used in the presence errors
- not using a walkDecl abstraction for const/var/type declarations
Change-Id: I5cf26779c9939b686a3dbaa4d38fdd0c154a92ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/305570
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Change-Id: I78c5744bb01988f1f599569703d83fd21542ac7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/305911
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: Iff5074713e1a4484c04b8628fb2611b6d4e154c7
GitHub-Last-Rev: bb0861bbbe
GitHub-Pull-Request: golang/go#45294
Reviewed-on: https://go-review.googlesource.com/c/go/+/305772
Reviewed-by: Ben Shi <powerman1st@163.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I75d089a7c1c3cdd50e5d2dafdb3386620efff4c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/304454
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>
For #45104
For #45221
Change-Id: I8966555f4e8844d5b6766d00d48f7a81868ccf40
Reviewed-on: https://go-review.googlesource.com/c/go/+/304453
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The setting of n.Use for a call node in transformCall() (and previously
in Call()), was not corrrect, since it was trying to use the number of
results of the call, rather than whether the call result was actually
used. We are already setting n.Use to ir.CallUseStmt if the call node is
directly a statement, so we just need to initialize n.Use to
ir.CallExprStmt in Call(), which will get changed to ir.CallUseStmt at
the statement level if it's used as a statement.
Enable inlining of stenciled functions (just disabled for testing,
easier debugging). The above n.Use fix was required for the inlining
to work for two cases.
Change-Id: Ie4ef6cd53fd4b20a4f3be31e629280909a545b7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305913
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>
During substitution of the function type during stenciling, we must set
the Name nodes of the param/result fields of the func type. We get those
name nodes from the substituted Dcl nodes of the PPARAMS and PPARAMOUTs.
But we must check that the names match with the Dcl nodes, so that we
skip any param fields that correspond to unnamed (in) parameters.
Added a few tests to typelist.go by removing a variety of unneeded
function parameter names.
Change-Id: If786961b64549da6f18eeeb5060ea58fab874eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/305912
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: I96170f1ca481b5fe21c85f99e877fa090e4dccc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/304452
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>
parsePrimaryExpr has to be careful to resolve identifiers used in
composite expressions when parsing in LHS mode. It missed the literal
type name.
Fixes#45136
Change-Id: I3e12f91e3ef5fdb43faa436cdf1240eb3293fe1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/304451
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>
Add new tests for object resolution driven by source files with
declarations and uses marked via special comments. This made it easier
to add test coverage while refactoring object resolution for #45104.
Tests are added to a new resolver_test.go file. In a subsequent CL the
resolver.go file will be added, making this choice of file name more
sensible.
For #45104
For #45136
For #45160
Change-Id: I240fccc0de95aa8f2d03e39c77146d4c61f1ef9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/304450
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
In expand_calls, when rewriting OpArg to OpArgIntReg/OpArgFloatReg,
avoid generating duplicates. Otherwise it will confuse the
register allocator: it would think the second occurance clobbers
the first's register, causing it to generate copies, which may
clobber other args.
Change-Id: I4f1dc0519afb77500eae1c0e6ac8745e51f7aa4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306029
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
