No functional changes except for import declaration and comment
adjustments.
Change-Id: I75fb5edba8b89a5aad7c9b4ddb427c201265def0
Reviewed-on: https://go-review.googlesource.com/c/go/+/331515
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This change moves the position information to the place where it
is actually used. It also simplifies getting rid of it after use.
In the process, fixed a latent bug: Before this CL, embedded types
were sorted, but the corresponding embedding positions were not.
Removed the sorting altogether as it is not needed for type-checking.
Change-Id: I48003f317196d814326424430336b6cb222fdee6
Reviewed-on: https://go-review.googlesource.com/c/go/+/331514
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Simplified names and unnecessary function indirections where possible.
Change-Id: I1c7a386393d086fd7ad29f892e03f048781f3547
Reviewed-on: https://go-review.googlesource.com/c/go/+/331512
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
With this change, interfaces are "completed" on-demand, when needed,
and the respective information (set of all methods, type constraints)
is recorded in a new typeSet data structure.
As a consequence, interfaces don't need to be explicitly completed
anymore and (internal) uses of interfaces have become much simpler.
This change also introduces a new field Interface.complete to indicate
that all methods and embedded elements have been set up. This prevent
the computation and recording (!) of a partial type set for erroneous
programs (if we compute the partial type set and store it, subsequent
type set accesses use the wrong type set which may lead to follow-on
errors).
Change-Id: I1ffc907f7d0fb93b3e987fe5ff9c6fa5cae00d7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/329309
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>
For #46557Fixes#46991
Change-Id: Ic88ebaa13d3edf904657dc19ada4fd4ff7f44a8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/332010
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The IsNotExist function is deprecated; change package example to avoid
it and use the recommended way instead.
Fixes#46976
Change-Id: I3c301d0a89b6bda42184df314ba8418062ca39ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/331692
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL updates the unified IR export data serialization to explicitly
and separately record the derived types used by a declaration. The
readers currently just use this data to construct types/IR the same as
before, but eventually we can use it for emitting GC-shape
dictionaries.
Change-Id: I7d67ad9b3f1fbe69664bf19e056bc94f73507220
Reviewed-on: https://go-review.googlesource.com/c/go/+/331829
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
These types already implemented the Image interface. They should also
implement the RGBA64Image interface (new in Go 1.17)
Updates #44808
Change-Id: I9a2b13e305997088ae874efb95ad9e1648f94812
Reviewed-on: https://go-review.googlesource.com/c/go/+/331570
Trust: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
If a certificate contains an AuthorityKeyIdentifier extension that
lacks the keyIdentifier field, but contains the authorityCertIssuer
and/or the authorityCertSerialNumber fields, don't return an error and
continue parsing.
Fixes#46854
Change-Id: I82739b415441f639a722755cc1f449d73078adfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/331689
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TestCVE202133195 fails in testing LookupSRV if /etc/resolv.conf sets the option
'ndots' larger than the number of dots in the domain name under query.
Fix the issue by making the input domain name in test codes 'rooted' to skip search
list qualifying.
Fixes#46955
Change-Id: I1909fa7e54e9c9af57623e57cafc905729ff99fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/330842
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This CL handles I(x) where I is an interface type and x has
typeparam type.
Change-Id: Ib99de2b741d588947f5e0164255f6365e98acd8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/326189
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>
Separate generation of instantiation and dictionary name generation.
Add code to add subdictionaries to a dictionary. Not quite working
yet, as we need to trigger generation of the subdictionaries for methods.
Change-Id: I0d46053eba695b217630b06ef2f990f6a0b52d83
Reviewed-on: https://go-review.googlesource.com/c/go/+/331209
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Change-Id: I0c2d26d6ede1452008992efbea7392162da65014
Reviewed-on: https://go-review.googlesource.com/c/go/+/331651
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 255241 made error message involving variadic calls clearer. To do it,
we added a check that the type of variadic argument must be a slice.
That's why the compiler crashes for invalid variadic argument type.
Instead, we can just omit the details error message, and report not
enough arguments error, which matches the behavior of go/types and types2.
Fixes#46957
Change-Id: I638d7e8f031f0ee344d5d802104fd93a60aae00a
Reviewed-on: https://go-review.googlesource.com/c/go/+/331569
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>
For arm64 CMP, ADD and other similar extended register instructions,
if there is no extension, the default extion is LSL<<0, but the default
encoding value (the value of 'option' field) of 32-bit instruction and
64-bit instruction is different, 32-bit is 2 and 64-bit is 3. But the
current assembler incorrectly encodes the value of 32-bit instruction
to 3. This CL fixes this error.
Change-Id: I0e09af2c9c5047a4ed2db7d1183290283db9c31c
Reviewed-on: https://go-review.googlesource.com/c/go/+/329749
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: eric fang <eric.fang@arm.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Not having a field name for the method is not really correct, and makes
it look like an embedded field. In fact, currently types.CalcSize() in
abitest() is creating an error that is not actually reported.
Change-Id: I98c3a4abf5b6d610d9c3c56ce1042078374b5417
Reviewed-on: https://go-review.googlesource.com/c/go/+/331469
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL removes the unconditional OCHECKNIL check added in
walkUnsafeSlice by instead passing it as a pointer to
runtime.unsafeslice, and hiding the check behind a `len == 0` check.
While here, this CL also implements checkptr functionality for
unsafe.Slice and disallows use of unsafe.Slice with //go:notinheap
types.
Updates #46742.
Change-Id: I743a445ac124304a4d7322a7fe089c4a21b9a655
Reviewed-on: https://go-review.googlesource.com/c/go/+/331070
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>
Change-Id: Ieff0065cbd81e045594ce12e10338b0666816d70
GitHub-Last-Rev: d842f5cb3e
GitHub-Pull-Request: golang/go#46949
Reviewed-on: https://go-review.googlesource.com/c/go/+/331309
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Allow fix for issue46725 to work for -G=3 mode.
Change-Id: Id522fbc2278cf878cb3f95b3205a2122c164ae29
Reviewed-on: https://go-review.googlesource.com/c/go/+/331470
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL adds GOEXPERIMENT to `go env` output, and also makes it
configurable via `GOENV`. Thanks to Baokun Lee's CL 304350 for the
test and initial work on this.
Fixes#45226.
Change-Id: Ie7f92a8a503b6a2a4df3f6598f0b2bf2915e2e7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/328751
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL refactors code a little to make it easier to add GOEXPERIMENT
support in the future.
Change-Id: I87903056f7863049e58be72047b2b8a60a213baf
Reviewed-on: https://go-review.googlesource.com/c/go/+/329654
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
the test case is still using gcc when CGO is disabled.
Change-Id: I2d255bfaeb92816c8343ab72fd7984b6632d421d
GitHub-Last-Rev: de14748bd5
GitHub-Pull-Request: golang/go#46120
Reviewed-on: https://go-review.googlesource.com/c/go/+/319169
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Change-Id: I303edc9dfbf4185b5b461b121ab504f6ed9f8630
Reviewed-on: https://go-review.googlesource.com/c/go/+/330839
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
walk is the only pass that use the function, so un-export it, too.
Change-Id: I32ec64d1c15fda7bb54bd8efa528ed32c102876d
Reviewed-on: https://go-review.googlesource.com/c/go/+/330841
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>
So next CL can move MethodValueWrapper to walk, since when walk is now
the only place which uses this function.
Change-Id: Id3be359bfc38efb022451cb7f9e53c2868fe7e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/330840
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>
As walk already create the wrapper if necessary.
With this change, test/inline.go need to be changed to use
errorcheckwithauto, for matching "inlining call to ..." in autogenerated
position for method value wrapper, since when we don't generate the
wrapper immediately during typecheck.
Change-Id: I9ffbec9ad3c2b7295546976e2fa517336c13c89b
Reviewed-on: https://go-review.googlesource.com/c/go/+/330838
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>
Go spec call them "method values", not "partial calls". Note that
we use "OMETHVALUE" (as opposed to "OMETHODVALUE") to be consistent
with "OMETHEXPR".
Change-Id: I1efd985d4b567a1b4b20aeb603eb82db579edbd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/330837
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 extracts out a ParseGOEXPERIMENT helper function that parses
GOOS/GOARCH/GOEXPERIMENT values and returns active and baseline
experiment flag sets and an error value, without affecting any global
state. This will be used in the subsequent CL for 'go env' support for
GOEXPERIMENT to validate configuration changes.
The existing package initialization for Experiment and
experimentBaseline and also UpdateExperiments are updated to use it as
well.
Change-Id: Ic2ed3fd36d2a6f7f3d8172fccb865e02505c0052
Reviewed-on: https://go-review.googlesource.com/c/go/+/331109
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Method value wrappers will need dictionary support too, so bring them
under the unified IR umbrella as well.
Change-Id: Iec36bb04efdf59843d1b00f55d2c44bc841fa2ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/331190
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Instead, just testing the runtime package in short mode instead of std.
So trybot can help catching any mistake earlier.
Change-Id: I5bc859a59afa13a10d436a798258ac154c7d27b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/330836
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>
CL 330831 moved rewrite method calls to typecheck pass, then add Fatalf
check for mis-used of OCALLMETH in all frontend passes. The check in SSA
generation pass is now redundant.
Change-Id: If959b774ab3c3aeefabf32333f77b9a93c156ce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/330834
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>
CL 330671 move rewriting method call to method expression to escape
analysis. This CL move the rewriting up further, into typecheck. It
helps simplify the code for dowstream passes, as they now only have to
deal with OCALLFUNC.
There're two notes:
- For -G=3, we can't rewrite d.M() where d is an instantiated receiver
in transformCall, but let irgen.stencil to rewrite it.
- Escape analysis still have to check for rewriting method calls, as
the devirtualization pass can still generate OCALLMETH.
Does not pass toolstash, since when the export data now contains method
expression calls instead of method calls.
Change-Id: I77465ef04d50dc4efedddca7eb55b3fc9483db0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/330831
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>
Since when walkCall1 still need to handle OCALLMETH.
Change-Id: Iadb12a0965169c63f97978c96412012ef4fa02df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330833
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>
CL 330671 moved rewrite method calls to escape analysis. It accidently
made the AST invalid, by removing the OCALLMETH set operation during
devirtualization pass.
Change-Id: I862ffd7f880de55969d7784d9e7b3c38894f6b68
Reviewed-on: https://go-review.googlesource.com/c/go/+/330832
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 changes typecheck and order to use Type.LinkString for
computing map keys instead of Type.NameString. As mentioned in the
LinkString docs (added by the previous CL), LinkString reliably maps
type identity to string equality as long as the LinkString calls all
happen within the same compilation unit (which they do here).
This eliminates the need for subsequent types.Identical checks.
Change-Id: I32ff591e69d6f23f2dc6ebd5af343618ebe89013
Reviewed-on: https://go-review.googlesource.com/c/go/+/330911
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The original names "ShortString" and "LongString" refer back to the
fmt verbs used to request their formatting styles. However, I always
get confused working with them, in particular because (1) the
"ShortString" description, which uses package-path qualification, is
actually generally longer than the "LongString" description, which
uses package-name qualification; and (2) the documentation mentions
how they're often used, but doesn't actually describe why they're safe
for those purposes.
This CL renames them to "LinkString" and "NameString", respectively,
based on their primary use cases. It also attempts to more completely
describe the strings they return and how they can be used correctly.
Change-Id: I9158ae3eafa8ac53da31a78c7a6d929dc0199afe
Reviewed-on: https://go-review.googlesource.com/c/go/+/330910
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
All other test files in the runtime/race package have race build
tag, except syso_test.go. The test is only relevant if the race
detector is supported. So apply the build tag.
Fixes#46931.
Change-Id: Icdb94214d3821b4ccf61133412ef39b4d7cc7691
Reviewed-on: https://go-review.googlesource.com/c/go/+/331050
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Elias Naur <mail@eliasnaur.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
TestCheck/issues.src was failing after running
rm -r $(go env GOROOT)/pkg/*/cmd
as the builders do when building binary releases.
For users who write programs that depend on go/types, it should be
reasonable for end users to run the tests for go/types as part of 'go
test all', and those tests should pass even if they installed Go from
a binary release.
The test case in issues.src was importing cmd/compile/internal/syntax
in order to check the reported package name.
I tried to fix the problem by having the test import from source
instead of from export data. Unfortunately, that changed the behavior
under test: the go/types.Package.Imports reports (and is documented to
report) a different set of imported packages when loading from source
as compared to when loading from export data.
For this particular test, after CL 313035 that difference resulted in
go/types treating the "syntax" name as ambiguous when importing from
source, because a transitive dependency on "regexp/syntax" is found
when loading from source but omitted when loading from export data.
The simple fix to make the package unambiguous again is to adapt the
test to import regexp/syntax directly. That not only makes the package
unambiguous with all importers, but also avoids depending on a
cmd-internal package that cannot be loaded from export data in binary
distributions of the Go toolchain.
For #43232
Change-Id: Iba45a680ea20d26daa86ac538fd8f1938e8b73ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/330431
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TestStdlib was failing after running
rm -r $(go env GOROOT)/pkg/*/cmd
as the builders do when building binary releases.¹
For users who write programs that depend on go/types, it should be
reasonable to run the tests for go/types as part of 'go test all', and
those tests should pass even if they installed Go from a binary
release.
I had originally drafted this as a fallback to import from source only
if the affected packages can't be imported by the default export-data
importer. Unfortunately, I realized that we don't currently have a
builder that tests the actual release (#46900), so it is quite likely
that the fallback path would bit-rot and produce unexpected test
regressions.
So instead, we now unconditionally import from source in TestStdlib.
That makes the test substantially slower (~15s instead of ~5s on my
workstation), but with less risk of regression, and TestStdlib is
skipped in short mode already so short-mode test time is unaffected.
If we change the builders to test the actual release configuration, we
can consider restoring the faster path when export data is available.
¹df58bbac08/cmd/release/release.go (L533-L545)
For #43232
Change-Id: I764ec56926c104053bb2ef23cf258c8f0f773290
Reviewed-on: https://go-review.googlesource.com/c/go/+/330252
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
ncgocall was stored per M, runtime.NumCgoCall lost the counter when a M die.
Fixes#46789
Change-Id: I85831fbb2713f4c30d1800d07e1f47aa0031970e
GitHub-Last-Rev: cbc15fa870
GitHub-Pull-Request: golang/go#46842
Reviewed-on: https://go-review.googlesource.com/c/go/+/329729
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
We need to start the capture walk from expr.Body, not expr, otherwise
in quirks mode we'll set all of the captured variables' positions to
expr.Body.Rbrace.
Change-Id: Ic93f2773ae3756c2ec88dac17b4e9fb5a0771734
Reviewed-on: https://go-review.googlesource.com/c/go/+/330889
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>
This CL extends unified IR to handle creating wrapper methods. There's
relatively little about this code that's actually specific to unified
IR, but rewriting this logic allows a few benefits:
1. It decouples unified IR from reflectdata.methodWrapper, so the
latter code can evolve freely for -G=3's needs. This will also allow
the new code to evolve to unified IR's wrapper needs, which I
anticipate will operate slightly differently.
2. It provided an opportunity to revisit a lot of the code and
simplify/update it to current style. E.g., in the process, I
discovered #46903, which unified IR now gets correctly. (I have not
yet attempted to fix reflectdata.methodWrapper.)
3. It gives a convenient way for unified IR to ensure all of the
wrapper methods it needs are generated correctly.
For now, the wrapper generation is specific to non-quirks mode.
Change-Id: I5798de6b141f29e8eb6a5c563e7049627ff2868a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330569
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>
This CL refactors out a single reflectdata.NeedEmit function that
reports whether the current compilation unit needs to emit the runtime
type descriptor and method wrappers for a given type.
As a minor side bonus, this CL also skips compiling the "error.Error"
wrapper in non-runtime packages. Package runtime already
unconditionally emitted the runtime type descriptor for error, so we
just need to make sure it emits the wrapper and other packages don't.
Passes toolstash -cmp.
Change-Id: Ic9ea219dfba8a0a57f2f42f817bdff7618732bff
Reviewed-on: https://go-review.googlesource.com/c/go/+/330754
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>
This CL refactors CaptureVars to use a visitor type so it's easier to
break out helper functions to review.
It also simplifies the quirks-mode handling of function literals:
instead of trying to maintain information about whether we're inside a
function literal or not, it now just rewrites the recorded position
information for any newly added free variables after walking the
function literal.
(Quirks mode is only for "toolstash -cmp"-style binary output testing
of normal code and will eventually be removed, so I don't think it's
important that this is an O(N^2) algorithm for deeply nested function
literals with lots of free variables.)
Change-Id: I0689984f6d88cf9937d4706d2d8de96415eaeee3
Reviewed-on: https://go-review.googlesource.com/c/go/+/330789
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>
