We decide during escape analysis whether to pass closure variables by
value or reference. One of the factors that's considered is whether a
variable has had its address taken.
However, this analysis is based only on the user-written source code,
whereas order+walk may introduce rewrites that take the address of a
variable (e.g., passing a uint16 key by reference to the size-generic
map runtime builtins).
Typically this would be harmless, albeit suboptimal. But in #43701 it
manifested as needing a stack object for a function where we didn't
realize we needed one up front when we generate symbols.
Probably we should just generate symbols on demand, now that those
routines are all concurrent-safe, but this is a first fix.
Thanks to Alberto Donizetti for reporting the issue, and Cuong Manh Le
for initial investigation.
Fixes#43701.
Change-Id: I16d87e9150723dcb16de7b43f2a8f3cd807a9437
Reviewed-on: https://go-review.googlesource.com/c/go/+/284075
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The feature being tested is insensitive to the OS anyway.
Change-Id: Ieac9bfaafc6a54c00017afcc0b87bd8bbe80af7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/284032
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>
fmt.go:dumpNodeHeader uses reflection to call all "func() bool"-typed
methods on Nodes during printing, but the OnStack method that I added
in CL 283233 isn't meant to be called on non-variables.
dumpNodeHeader does already guard against panics, as happen in some
other accessors, but not against Fatalf, as I was using in OnStack. So
simply change OnStack to use panic too.
Thanks to drchase@ for the report.
Change-Id: I0cfac84a96292193401a32fc5e7fd3c48773e008
Reviewed-on: https://go-review.googlesource.com/c/go/+/284074
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
On Apple Silicon Mac, the C compiler has an annoying default
target selection, depending on the ancestor processes'
architecture. In particular, if the shell or IDE is x86, when
running "go build" even with a native ARM64 Go toolchain, the C
compiler defaults to x86, causing build failures. We pass "-arch"
flag explicitly to avoid this situation.
Fixes#43692.
Fixes#43476.
Updates golang/vscode-go#1087.
Change-Id: I80b6a116a114e11e273c6886e377a1cc969fa3f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/283812
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The cgo header has an unnecessary space in the exported function
definition on non-windows goos.
This was introduced in go1.16 so it would be good to fix it before
release.
Example:
// Current behavior, notice there is an unecessary space
// between extern and void
extern void Foo();
// With this CL
extern void Foo();
Change-Id: Ic2c21f8d806fe35a7be7183dbfe35ac605b6e4f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/283892
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Katie Hockman <katie@golang.org>
For #29062Fixes#43263
Change-Id: I160197c94cc4f936967cc22c82cec01663a14fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/283873
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This partially addresses the issue below: In many (all) cases we want to
handle invalid ... use in the parser as a syntax error; but this ensures
that we get a decent error if we get here anyway.
Updates #43680.
Change-Id: I93af43a5f5741d8bc76e7a13c0db75e6edf43111
Reviewed-on: https://go-review.googlesource.com/c/go/+/283475
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This patch pulls in a few additional changes requested by code
reviewers for CL 270863 that were accidentally left out. Specifically,
guarding use of ORETJMP to insure it is not used when building dynlink
on ppc64le, and a tweaking the command line flags used to control
wrapper generation.
Change-Id: I4f96462e570180887eb8693e11badd83d142710a
Reviewed-on: https://go-review.googlesource.com/c/go/+/279527
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Than McIntosh <thanm@google.com>
Consider the following example,
func test(a, b float64, x uint64) uint64 {
if a < b {
x = 0
}
return x
}
func main() {
fmt.Println(test(1, math.NaN(), 123))
}
The output is 0, but the expectation is 123.
This is because the rewrite rule
(CSEL [cc] (MOVDconst [0]) y flag) => (CSEL0 [arm64Negate(cc)] y flag)
converts
FCMP NaN, 1
CSEL MI, 0, 123, R0 // if 1 < NaN then R0 = 0 else R0 = 123
to
FCMP NaN, 1
CSEL GE, 123, 0, R0 // if 1 >= NaN then R0 = 123 else R0 = 0
But both 1 < NaN and 1 >= NaN are false. So the output is 0, not 123.
The root cause is arm64Negate not handle negation of floating comparison
correctly. According to the ARM manual, the meaning of MI, GE, and PL
are
MI: Less than
GE: Greater than or equal to
PL: Greater than, equal to, or unordered
Because NaN cannot be compared with other numbers, the result of such
comparison is unordered. So when NaN is involved, unlike integer, the
result of !(a < b) is not a >= b, it is a >= b || a is NaN || b is NaN.
This is exactly what PL means. We add NotLessThanF to represent PL. Then
the negation of LessThanF is NotLessThanF rather than GreaterEqualF. The
same reason for the other floating comparison operations.
Fixes#43619
Change-Id: Ia511b0027ad067436bace9fbfd261dbeaae01bcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283572
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Renamed setErrorPos to setPos, made it a method of PackageError,
and removed its Package parameter and return value. This makes it
more clear that setPos modifies PackageError and does not create a new
Package.
Change-Id: I26c58d3d456c7c18a5c2598e1e8e158b1e6b4b36
Reviewed-on: https://go-review.googlesource.com/c/go/+/283637
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
For #43469
For #43632
Change-Id: I9ac2da690344935da0e1dbe00b134dfcee65ec8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/283636
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
CL 283672 added a flag to prevent double walking, use that flag instead
of checking SwitchStmt.Compiled field.
Passes toolstash -cmp.
Change-Id: Idb8f9078412fb789f51ed4fc4206638011e38a93
Reviewed-on: https://go-review.googlesource.com/c/go/+/283733
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>
This CL moves almost all PAUTOHEAP handling code to SSA construction.
Instead of changing Names to PAUTOHEAP, escape analysis now only sets
n.Esc() to ir.EscHeap, and SSA handles creating the "&x"
pseudo-variables and associating them via Heapaddr.
This CL also gets rid of n.Stackcopy, which was used to distinguish
the heap copy of a parameter used within a function from the stack
copy used in the function calling convention. In practice, this is
always obvious from context: liveness and function prologue/epilogue
want to know about the stack copies, and everywhere else wants the
heap copy.
Hopefully moving all parameter/result handling into SSA helps with
making the register ABI stuff easier.
Also, the only remaining uses of PAUTOHEAP are now for closure
variables, so I intend to rename it to PCLOSUREVAR or get rid of those
altogether too. But this CL is already big and scary enough.
Change-Id: Ief5ef6205041b9d0ee445314310c0c5a98187e77
Reviewed-on: https://go-review.googlesource.com/c/go/+/283233
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reduce 16 byte for CallExpr, from 184 to 168 on 64-bit archs.
Passes toolstash -cmp.
Change-Id: I59c7609ccd03e8b4a7df8d2c30de8022ae312cee
Reviewed-on: https://go-review.googlesource.com/c/go/+/283732
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, there's an awkward issue with walk pass. When walking the AST
tree, the compiler generate code for runtime functions (using mkcall* variants),
add/modify the AST tree and walk new generated tree again. This causes the
double walking on some CallExpr, which is relying on checking Rargs to prevent
that. But checking Rargs has its own issue as well.
For functions that does not have arguments, this check is failed, and we
still double walk the CallExpr node.
This CL change the way that compiler detects double walking, by using
separated field instead of relying on Rargs. In perfect world, we should make
the compiler walks the AST tree just once, but it's not safe to do that at
this moment.
Passes toolstash -cmp.
Change-Id: Ifdd1e0f98940ddb1f574af2da2ac7f005b5fcadd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283672
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>
This CL adds "irgen", a new noding implementation that utilizes types2
to guide IR construction. Notably, it completely skips dealing with
constant and type expressions (aside from using ir.TypeNode to
interoperate with the types1 typechecker), because types2 already
handled those. It also omits any syntax checking, trusting that types2
already rejected any errors.
It currently still utilizes the types1 typechecker for the desugaring
operations it handles (e.g., turning OAS2 into OAS2FUNC/etc, inserting
implicit conversions, rewriting f(g()) functions, and so on). However,
the IR is constructed in a fully incremental fashion, so it should be
easy to now piecemeal replace those dependencies as needed.
Nearly all of "go test std cmd" passes with -G=3 enabled by
default. The main remaining blocker is the number of test/run.go
failures. There also appear to be cases where types2 does not provide
us with position information. These will be iterated upon.
Portions and ideas from Dan Scales's CL 276653.
Change-Id: Ic99e8f2d0267b0312d30c10d5d043f5817a59c9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281932
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
CL 278914 introduced NameOffsetExpr to avoid copying ONAME nodes and
hacking up their offsets, but evidently staticinit subtly depended on
the prior behavior to allow dynamic initialization of blank variables.
This CL refactors the code somewhat to avoid using NameOffsetExpr with
blank variables, and to instead create dynamic assignments directly to
the global blank node. It also adds a check to NewNameOffsetExpr to
guard against misuse like this, since I suspect there could be other
cases still lurking within staticinit. (This code is overdue for an
makeover anyway.)
Thanks to thanm@ for bisect and test case minimization.
Fixes#43677.
Change-Id: Ic71cb5d6698382feb9548dc3bb9fd606b207a172
Reviewed-on: https://go-review.googlesource.com/c/go/+/283537
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When a command fails due to a module zip sum missing from go.sum,
if the module is in the build list, the go command will print a
'go mod download' command the user can run to fix it.
Previously, a hint was only printed if the module provided a package
in 'all'. We don't print a 'go get' hint, since we may not want to add
a new requirement to go.mod.
Fixes#43572
Change-Id: I88c61b1b42ad56c04e4482f6a1bb97ce758aaeff
Reviewed-on: https://go-review.googlesource.com/c/go/+/282712
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
I misread the FIXME comment in InitLSym the first time. It's referring
to how InitLSym is supposed to be called exactly once per
function (see function documentation), but this is evidently not
actually the case currently in GOEXPERIMENT=regabi mode.
So just move the NeedFuncSym call below the GOEXPERIMENT=regabi
workaround.
Also, to fix the linux-arm64-{aws,packet} builders, move the call to
reflectdata.WriteFuncSyms() to after the second batch of functions are
compiled. This is necessary to make sure we catch all the funcsyms
that can be added by late function compilation.
Change-Id: I6d6396d48e2ee29c1fb007fa2b99e065b36375db
Reviewed-on: https://go-review.googlesource.com/c/go/+/283552
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Needs to be visible to ssagen, and might as well start clean to avoid
creating a lot of accidental dependencies.
Added some methods for export.
Decided to use a pointer instead of value for ABIConfig uses.
Tests ended up separate from abiutil itself; otherwise there are import cycles.
Change-Id: I5570e1e6a463e303c5e2dc84e8dd4125e7c1adcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/282614
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: Jeremy Faller <jeremy@golang.org>
This only works for functions; if you try it with a method, it will
fail. It does work for both local package and imports. For now,
it tells you when it thinks it sees either a declaration or a call of
such a function (this will normally be silent since no existing
code uses this pragma).
Note: it appears to be really darn hard to figure out if this
pragma was set for a method, and the method's call site. Better
ir.Node wranglers than I might be able to make headway, but it
seemed unnecessary for this experiment.
Change-Id: I601c2ddd124457bf6d62f714d7ac871705743c0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/279521
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This is a selected copy from the register ABI experiment CL, focused
on the files and data structures that handle spilling around morestack.
Unnecessary code from the experiment was removed, other code was adapted.
Would it make sense to leave comments in the experiment as pieces are
brought over?
Experiment CL (for comparison purposes)
https://go-review.googlesource.com/c/go/+/28832
Change-Id: I92136f070351d4fcca1407b52ecf9b80898fed95
Reviewed-on: https://go-review.googlesource.com/c/go/+/279520
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This is intended to make it easier to write/change a test
without referring to the source code to figure out what the
error messages actually mean, or how to correct them.
Change-Id: Ie79ff7cd9f2d1fa605257fe97eace68adc8a6716
Reviewed-on: https://go-review.googlesource.com/c/go/+/281452
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Current many architectures use a rule along the lines of
// Canonicalize the order of arguments to comparisons - helps with CSE.
((CMP|CMPW) x y) && x.ID > y.ID => (InvertFlags ((CMP|CMPW) y x))
to normalize comparisons as much as possible for CSE. Replace the
ID comparison with something less variable across compiler changes.
This helps avoid spurious failures in some of the codegen-comparison
tests (though the current choice of comparison is sensitive to Op
ordering).
Two tests changed to accommodate modified instruction choice.
Change-Id: Ib35f450bd2bae9d4f9f7838ceaf7ec682bcf1e1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280155
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>
The closure's type always matches the corresponding function's type,
so just use one instance rather than carrying around two. Simplifies
construction of closures, rewriting them during walk, and shrinks
memory usage.
Passes toolstash -cmp.
Change-Id: I83b8b8f435b02ab25a30fb7aa15d5ec7ad97189d
Reviewed-on: https://go-review.googlesource.com/c/go/+/283152
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
We used to transform directly called closures in a separate pass
before walk, because we couldn't guarantee whether we'd see the
closure call or the closure itself first. As of the last CL, this
ordering is always guaranteed, so we can rewrite calls and the closure
at the same time.
Change-Id: Ia6f4d504c24795e41500108589b53395d301123b
Reviewed-on: https://go-review.googlesource.com/c/go/+/283315
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL reorders function compilation to ensure that functions are
always compiled before any enclosed function literals. The primary
goal of this is to reduce the risk of race conditions that arise due
to compilation of function literals needing to inspect data from their
closure variables. However, a pleasant side effect is that it allows
skipping the redundant, separate compilation of function literals that
were inlined into their enclosing function.
Change-Id: I03ee96212988cb578c2452162b7e99cc5e92918f
Reviewed-on: https://go-review.googlesource.com/c/go/+/282892
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
No real code changes. Just splitting into a separate CL so the next
one is easier to review.
Change-Id: I428dc986b76370d8d3afc12cf19585f6384389d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/283314
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The compiler currently has two modes for compilation: one where it
compiles each function as it sees them, and another where it enqueues
them all into a work queue. A subsequent CL is going to reorder
function compilation to ensure that functions are always compiled
before any non-trivial function literals they enclose, and this will
be easier if we always use the compile work queue.
Also, fewer compilation modes makes things simpler to reason about.
Change-Id: Ie090e81f7476c49486296f2b90911fa0a466a5dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283313
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
InitLSym is where we're now generating ABI wrappers, so it seems as
good a place as any to make sure we're generating the degenerate
closure wrappers for declared functions and methods.
Change-Id: I097f34bbcee65dee87a97f9ed6f3f38e4cf2e2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/283312
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
For #36460
Updates #36465
Change-Id: Id818dce21d39a48cf5fc9c015b30497dce9cd1ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/278596
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Just directly set Type.Vargen when declaring defined types within a
function.
Change-Id: Idcc0007084a660ce1c39da4a3697e158a1c615b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/283212
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Historically, inline function bodies were exported as plain Go source
code, and symbol mangling was a convenient hack because it allowed
variables to be re-imported with largely the same names as they were
originally exported as.
However, nowadays we use a binary format that's more easily extended,
so we can simply serialize all of a function's declared objects up
front, and then refer to them by index later on. This also allows us
to easily report unmangled names all the time (e.g., error message
from issue7921.go).
Fixes#43633.
Change-Id: I46c88f5a47cb921f70ab140976ba9ddce38df216
Reviewed-on: https://go-review.googlesource.com/c/go/+/283193
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Creating closure vars is subtle and is also needed in both CL 281932
and CL 283112, so refactor out a common implementation that can be
used in all 3 places.
Passes toolstash -cmp.
Change-Id: Ib993eb90c895b52759bfbfbaad88921e391b0b4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/283194
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL refactors noder's package import logic so it's easier to reuse
with types2 and gcimports. In particular, this allows the types2
integration to now support vendored packages.
Change-Id: I1fd98ad612b4683d2e1ac640839e64de1fa7324b
Reviewed-on: https://go-review.googlesource.com/c/go/+/282919
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL extracts and simplifies noder's DWARF scope tracking code to
make it easier for reuse by irgen.
The previous code tried to be really clever about avoid recording
multiple scope boundaries at the same position (as happens at the end
of "if" and "for" statements). I had a really hard time remember how
this code worked exactly, so I've reimplemented a simpler algorithm
that just tracks all scope marks, and then compacts them at the end
before saving them to the ir.Func.
Passes toolstash -cmp.
Change-Id: Ibeb37997b77dc5179360d7db557c82ae1682e127
Reviewed-on: https://go-review.googlesource.com/c/go/+/282918
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Import changes from go2go to automatically discover testdata-driven
check tests.
Tests for generics will be added in a subsequent CL.
Change-Id: I50d55141750caebf15f1f382e139edfe9920c14e
Reviewed-on: https://go-review.googlesource.com/c/go/+/283132
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>
Escape analysis needs to know the index of result parameters for
recording escape-flow information. It currently relies on Vargen for
this, but it can easily figure this out for itself. So just do that
instead, so that we can remove Vargen.
Passes toolstash -cmp.
For #43633.
Change-Id: I65dedc2d73bc25e85ff400f308e50b73dc503630
Reviewed-on: https://go-review.googlesource.com/c/go/+/283192
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Simplify the code and make it easier to reuse with irgen.
Change-Id: Id477c36e82c7598faa90025b1eed2606a3f82498
Reviewed-on: https://go-review.googlesource.com/c/go/+/282917
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL extracts the position mapping logic from noder and moves it
into a new posMap type, which can be more easily reused.
Passes toolstash -cmp.
Change-Id: I87dec3a3d27779c5bcc838f2e36c3aa8fabad155
Reviewed-on: https://go-review.googlesource.com/c/go/+/282916
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL adds an implementation of types2.Sizes that calculates sizes
using the same sizing algorithm as cmd/compile. In particular, it
matches how cmd/compile pads structures and includes padding in size
calculations.
Change-Id: I4dd8e51f95c90f9d7bd1e7463e40edcd3955a219
Reviewed-on: https://go-review.googlesource.com/c/go/+/282915
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Rerank editor plugins based on popularity (Go 2019 survey), and remove
Atom, as it is no longer popular.
Change-Id: I06d39b67eec24a920439b9ea1198b6e2a939874e
Reviewed-on: https://go-review.googlesource.com/c/go/+/283073
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL implements a number of minor fixes that were discovered in
getting -G=3 working for running all.bash.
1. Field tags were handled incorrectly. If a struct type had some
fields with tags, but later fields without tags, the trailing tag-less
fields would all copy the tag of the last tagged field. Fixed by
simply reinitializing `tag` to "" for each field visited.
2. Change the ending of switch case clause scopes from the end of the
last statement to the next "case" token or the switch-ending "}"
token. I don't think this is strictly necessary, but it matches my
intuition about where case-clause scopes end and cmd/compile's current
scoping logic (admittedly influenced by the former).
3. Change select statements to correctly use the scope of each
individual communication clause, instead of the scope of the entire
select statement. This issue appears to be due to the original
go/types code being written to rebind "s" from the *SelectStmt to the
Stmt in the range loop, and then being further asserted to "clause" of
type *CommClause. In most places within the loop body, "clause" was
used, but the rebound "s" identifier was used for the scope
boundaries.
However, in the syntax AST, SelectStmt directly contains a
[]*CommClause (rather than a *BlockStmt, with []Stmt), so no assertion
is necessary and instead of rebinding "s", the range loop was updated
to directly declare "clause".
4. The end position for increment/decrement statements (x++/x--) was
incorrectly calculated. Within the syntax AST, these are represented
as "x += ImplicitOne", and for AssignStmts types2 calculated the end
position as the end position of the RHS operand. But ImplicitOne
doesn't have any position information.
To workaround this, this CL detects ImplicitOne and then computes the
end position of the LHS operand instead, and then adds 2. In practice
this should be correct, though it could be wrong for ill-formatted
statements like "x ++".
Change-Id: I13d4830af39cb3f3b9f0d996672869d3db047ed2
Reviewed-on: https://go-review.googlesource.com/c/go/+/282914
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
