The value types in type assertions and type switches cannot be
constraint types (if there are, an error was reported earlier),
so there is no need to check again that they are not constraint
types.
This permits merging the ordinaryType call with varType, which
is the only place where it's needed.
Change-Id: I44a852377b3dddf53692f764e588801fb3d3c0a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/346291
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL makes two changes to how unified IR emits method wrappers:
1. It no longer emits wrappers for defined types' underlying
types. Previously, a declaration like `type T struct { U }` would emit
wrappers for both `T` and `struct { U }`. Now they're only emitted for
`T`.
2. It emits method value wrappers only when OMETHVALUE nodes are
actually created, like how -G=0 works. Method values are relatively
rare, aren't needed for runtime type descriptors (unlike method
expression wrappers), and large projects end up spending a non-trivial
amount of time compiling these unneeded wrappers.
Change-Id: I21da97df3132ec12cc67debf62b5b2d282f481cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/346230
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>
It seems everything is in place for these tests to pass on solaris and
illumos, so enable them.
Fixes#7399
Change-Id: If6defb651ef9c5059c1aeccbc4fc13a12a86b682
Reviewed-on: https://go-review.googlesource.com/c/go/+/346149
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This error reporting code path did not have test coverage, and panics in
1.17 (filed as #48082).
Add a test that would have reproduced the panic, for both go/types and
cmd/compile/internal/types2.
Change-Id: Icd5f54f8407e4ab57d432f44a129ecf6b2755feb
Reviewed-on: https://go-review.googlesource.com/c/go/+/346309
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
When using a typeWriter for debugging/error message type strings,
it shouldn't crash in the presence of type-checker internal bugs.
But when a typeHasher is used, we don't want to silently ignore
errors.
Introduce an error method that panics in type hashing mode but
prints an error value otherwise.
Also fixed an incorrect 'if' statement in tParamList.
Change-Id: I26c8b8e0b14396e91ad71bf903e36ce1ca55839e
Reviewed-on: https://go-review.googlesource.com/c/go/+/346009
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Instead, keep track of hashing mode with a typeWriter field.
Introduce a new constructor (newTypeHasher) to set the mode.
Change-Id: Ie69cc0382532c75973794326be15c884b7fdcb76
Reviewed-on: https://go-review.googlesource.com/c/go/+/345929
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Rename instanceHashing accordingly.
Eventually, this will make it possible to use typeHash to detect
multiple identical types in type switch cases and other places.
Also fix some bugs: When creating a type hash, the name of function
parameters must be ignored because they don't matter for type
identity. And when printing a type name, don't assume its type
is a *Named type; it could be a *Basic type as well.
Finally, use a correctly qualified type string when reporting
a duplicate type error in a type switch case rather than the
(debugging) type string.
Change-Id: Ida3873f6259b51847843b0e2d7e3aa2fcdc3a0c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/345791
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Use varType instead of instantiatedOperand to check if the type of a method expressions is instantiated.
This removes the last usage of instantiatedOperand, so it can be deleted.
Fixes#48048
Change-Id: I2b219dafe2bba3603100bb8f25b8ff4e8ef53841
Reviewed-on: https://go-review.googlesource.com/c/go/+/345970
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We were using the type from the wrong Node (the partially filled-in
FUNCINST) rather than the original function node - which is pointed to
by the OFUNCINST)) to set the final fully-substituted type of the
OFUNCINST. So fixed the node reference. Also, added check so we don't do
any work at all if the OFUNCINST already has all type args filled in.
Added few extra cases to the test file issue48030.go, to cover
fully-specified type args, partially inferred type args, and fully
inferred type args.
Fixes#48030
Change-Id: If9e4f2e0514d68b9d241f30c423259133932b25b
Reviewed-on: https://go-review.googlesource.com/c/go/+/346229
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Since we know whether we are printing a type string used as
instance hash, don't print instance markers, so that we don't
need to remove them afterwards either.
Change-Id: Ib01627b6da989ef89d51e734810a3377eb466925
Reviewed-on: https://go-review.googlesource.com/c/go/+/345891
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Rather then passing through a buffer, qualified, and visited
list to each helper function, maintain state in a typeWriter
object and use methods on it. This cleans up this code quite
a bit.
Use a map ("seen") for cycle detection rather than a list.
Move printing of [ and ] for type lists into the typeList
method so that callers don't have to do it themselves.
Change-Id: I1346373e979cb90710fbc073953aa51e2f6581f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/345890
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The level of support for pruning — not the lazy/eager loading behavior
— is the more fundamental property, and what matters in terms of what
invariants we need to maintain.
If the main module supports pruned module graphs we load its
dependencies lazily, and if it does not support pruned module graphs
we load its dependencies eagerly. However, in principle we could also
load the module graph lazily even in modules that do not support graph
pruning — we would just be more likely to overlook inconsistent
requirements introduced by hand-edits or bad VCS merges to the go.mod
file.
(After this change, a “lazy” module is just one in which we happen not
to have loaded the module graph, and an “eager” one is one in which we
happen to load the module graph more aggressively.)
Updates #36460
For #47397
Change-Id: I0d2ffd21acc913f72ff56b59a6bdc539ebc3d377
Reviewed-on: https://go-review.googlesource.com/c/go/+/345393
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>
Replace the last remaining use with a reference to #48024.
Change-Id: I699711b4e42abe9c6d3512c28d2ee81a84e3263a
Reviewed-on: https://go-review.googlesource.com/c/go/+/345392
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>
Fixes#48056
Change-Id: I13ca4caadbabf02084f66ab28b4cf0c4a3705370
Reviewed-on: https://go-review.googlesource.com/c/go/+/346049
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It's not needed outside of package types anymore.
Change-Id: Idadf915fc254920ca778b5f5f8de8a1300da1953
Reviewed-on: https://go-review.googlesource.com/c/go/+/345794
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: 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>
Once upon a time, this was used by package walk to compute the
"conv[TIE]2[TIE]" function names, etc.; but it seems like those
callers have all changed to directly specializing on IsInterface and
IsEmptyInterface instead.
Change-Id: I629cdf076a09e7255ae293b8f879db0cdcf4de5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/345793
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 issue has been fixed in https://golang.org/cl/345411Fixes: #47892
Change-Id: I13dd3814650913da065e5f24a0c61d30adb0633a
Reviewed-on: https://go-review.googlesource.com/c/go/+/345229
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is not implemented on AIX and Illumos, and we already have a
mechanism to skip the test case -- let's use it.
Change-Id: Idb1cc2d716cf6d0731e93dfc3aa7853b9edec41f
Reviewed-on: https://go-review.googlesource.com/c/go/+/330752
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
storeOneLoad decompose Load that is then stored, the offset value must
be created on the same block with the Load to be dominated, otherwise,
it's unsafe if one does not dominate the other.
Fixes#48026
Change-Id: Iee5e6c5d3e1b09862afe4e65f7bcd771b4c57367
Reviewed-on: https://go-review.googlesource.com/c/go/+/345434
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
b.Controls has type [2]*Value, thus len(b.Controls) > 0 is always true.
The right check should be b.Controls[0] != nil, though, this is also
always true, since when we always set control value for BlockRet and
BlockRetJmp when state.exit is called.
Though checkFunc also checks for nil control value of ret/retjmp, but
it happens later after expand_calls pass, so better to be defensive
here, just in case.
Change-Id: Ie4a292a3494dfbf5e6d872cde498703023b84d00
Reviewed-on: https://go-review.googlesource.com/c/go/+/345433
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Support 'type C comparable' properly by using the same logic as for
'type T error', since ErrorType and ComparableType are entirely
analogous.
Added support for 'any' type as well, as requested by Robert. (For the
future - we can't currently have 'any' anywhere other than in a
constraint.)
Fixes#47966
Change-Id: I68bd284ced9a8bfca7d2339cd576f3cb909b1b83
Reviewed-on: https://go-review.googlesource.com/c/go/+/345174
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>
Discover while working on moving checkptr instrumentation from walk to
SSA generation.
Change-Id: I3f4a41fe4ad308b86c7c57d14b6ccc7c613e7f98
Reviewed-on: https://go-review.googlesource.com/c/go/+/345432
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 343972 added SliceExpr.CheckPtrCall field but forgot to add ignore
tag for mknode. This CL adds the missing tag.
Change-Id: Ib39bff3d456063bdc10fc17b4047b8392d373bf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/345431
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>
AppendRune appends the UTF-8 encoding of a rune to a []byte.
It is a generally more user friendly than EncodeRune.
EncodeASCIIRune-4 2.35ns ± 2%
EncodeJapaneseRune-4 4.60ns ± 2%
AppendASCIIRune-4 0.30ns ± 3%
AppendJapaneseRune-4 4.70ns ± 2%
The ASCII case is written to be inlineable.
Fixes#47609
Change-Id: If4f71eedffd2bd4ef0d7f960cb55b41c637eec54
Reviewed-on: https://go-review.googlesource.com/c/go/+/345571
Trust: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Semantically, TypeObject is the interface that go/types.TypeName would
implement, so we might as well use that instead of the more generic
Object (analog to go/types.Object) for NewNamed. In practice, this
doesn't really matter though, because we use *ir.Name for almost all
Objects anyway.
Also, remove VarObject: its last use was removed in CL 302071 (March
2021).
Change-Id: I6e987ecd419105e09f74fc8d60cadb61bcbc751f
Reviewed-on: https://go-review.googlesource.com/c/go/+/345810
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
We already have a function that does all the right checks and it's called
varType. The only reason it wasn't used for type switch cases was that we
also have to accept the nil value. That was handled with typeOrNil. But
that function (typeOrNil) was only used for this specific purpose and I long
wished to get rid of it. It turns out that there's only one way to write the
untyped value nil, which is to actually write "nil" (maybe with parentheses).
So looking for that turned out to be simpler than using typeOrNil.
The new code does exactly that, and now we can just use varType and delete
typeOrNil. With this, there is now less code (excluding the test) and the code
is simpler and more correct.
Fixes#48008.
Change-Id: I8f2d80e61ae663c886924909f22bbfa634e7779c
Reviewed-on: https://go-review.googlesource.com/c/go/+/345790
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The current implementation of PtrDataSize checks HasPointers each
call, which could lead to exponential blow-up in handling (admittedly
contrived) deeply nested structs.
To avoid the duplicate recursion, this CL incorporates the HasPointers
logic directly int PtrDataSize, and then re-defines HasPointers as
simply "PtrDataSize(t) > 0".
This CL also tightens up HasPointers/PtrDataSize to only be valid on
actual Go types. Fortunately, there was only one instance where this
wasn't already the case (escape analysis), and that's easily fixed
with an extra check for untyped types.
Change-Id: I0044bf9b558a88333aee2ccb137afb6cb4fea1db
Reviewed-on: https://go-review.googlesource.com/c/go/+/345809
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>
Now that the universe is fully initialized within package types, we
can stop exporting New and NewBasic, which are only needed for that
purpose. So this CL renames "New" to "newType" and "NewBasic" to
"newBasic".
This CL also moves the initialization of Types[TBLANK] and Types[TNIL]
from typecheck.InitUniverse to types.InitTypes, which I missed in an
earlier CL. And a use of "New(TSTRING)" in test/abiutils_test.go,
which should just be "Types[TSTRING]" anyway.
Change-Id: I1d83f93e27b88be289d4f3f6c16357a20f570460
Reviewed-on: https://go-review.googlesource.com/c/go/+/345487
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>
Automated CL to rewrite existing code to use OrigSym getters and
setters. Afterwards, we also unexported OrigSym, and then rename the
getter to OrigSym.
[git-generate]
cd src/cmd/compile/internal
: Workaround rf issue with types2 tests.
rm types2/*_test.go
rf '
ex ./noder ./typecheck {
import "cmd/compile/internal/types"
var s *types.Sym
var t *types.Type
t.OrigSym = s -> t.SetOrigSym(s)
t.OrigSym -> t.OrigSym_()
}
'
cd types
rf '
mv Type.OrigSym Type.origSym
mv Type.OrigSym_ Type.OrigSym
'
: Revert types2 hack.
cd ../types2
git checkout HEAD^ .
Change-Id: I8eb17098613b1575df56b8189b1615823071d3d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/345485
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Will be used in the next CL, so that Type.OrigSym can be unexported.
Change-Id: I085f2a886abd419343c7ec7e4ae18c19de1fbbd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/345484
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>
Commands run:
go get golang.org/x/mod@master
go mod vendor
go mod tidy
This change pulls in the x/mod on master. Before it was pulled in on
the dev.cmdgo branch of x/mod, but now that the workspace changes have
been pulled into x/mod, we can change the requirement back on to the
main branch.
Change-Id: I296799a87ecc08ba17c0722e955f000426b105ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/345390
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Conversions need to allow nil through.
We do that using a CONVIFACE instead of a DOTTYPE.
Also reorganize how nonempty interfaces are handled.
For nonempty to empty, a simple CONVIFACE suffices.
For nonempty to nonempty, we need to call the runtime to get the
new itab. Use the entry from the dictionary to identify the
target interface type (if parameterized).
Fixes#47925
Change-Id: I4ffeed964318bb3e270b06f558e6ab9c5bfc7188
Reviewed-on: https://go-review.googlesource.com/c/go/+/344830
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>
type I[T any] interface{}
This is an interface, but it has a type parameter.
We need to distinguish that from an interface that is not parameterized.
That means when doing type substitution on an interface with
parameters, we need to make a new one.
Same for non-empty interfaces. Even if the type parameter is not
used in any method, we sill need to make a new type.
Similar case to tstruct, above.
Change-Id: I23ad9f21d2c4ef675bf3f7d84899d9e4919d05e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/344578
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>
The reflect.Value.Slice method unfortunately allocates every time
since it needs to place the slice header on the heap.
This is silly since gob immediately stores the result back into slice.
Instead, use the reflect.Value.SetLen method.
DecodeBytesSlice 75.0µs ± 2% 35.2µs ± 6% -53.02%
Change-Id: I3ca0529d01bf978f2b76e215f52d369f458951ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/345572
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Make sure the parser fills in names and types for type parameter
lists, even in the case of errors.
While at it, adjust some of the test functions to accept generic
code and report all syntax errors.
Added offending source as test for types2.
Fixes#47996.
Change-Id: I449bcf5e2cb80fa2a24cdd3945f484bfca218a06
Reviewed-on: https://go-review.googlesource.com/c/go/+/345476
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The next CL is going to replace Type.Width with Type.Size(), but
Type.Size() isn't safe to call concurrently. So this CL calls
CalcStructSize, which *is* allowed to be used concurrently, but then
it's the caller's responsibility to ensure it's called right after
NewStruct.
Change-Id: If9cd81650ccb3a867b4449af757375fa56227901
Reviewed-on: https://go-review.googlesource.com/c/go/+/345483
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>
We need to delay fillinMethods until we get to a top-level type, so we
know all the TFORW types have been filled in, and we can do the
substitutions required by fillinMethods.
Fixes#47710
Change-Id: I298de7e7753ed31a2c2b1ff04f35177a8afc7a66
Reviewed-on: https://go-review.googlesource.com/c/go/+/345149
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This is the only case where Align is assigned outside of package
types. Rather than adding a SetAlign method, adding a RecalcSize
function is a bit more descriptive.
Change-Id: I1b3c01ebd0e41183665baa63c926592865bbbd0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/345479
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This test was written in 2015, and hasn't had any meaningful changes
to it since. However, it's very ad hoc and pokes into internals that
it shouldn't, and it keeps getting in the way of more meaningful
refactorings. It doesn't even catch bugs; e.g., it didn't catch that
cmpstackvarlt wasn't asymmetric (CL 19778), and a bunch of its test
cases are bogus because we never actually use it to sort ir.PFUNC
nodes (assert added in this CL).
The compiler is woefully lacking in unit tests like these, but I
strongly feel this test is more of a hinderance than a help at the
moment.
Change-Id: I3ac7a3e533947aa95f325626c6eec13a43789f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/345478
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
