]> Cypherpunks.ru repositories - gostls13.git/commit
[dev.regabi] cmd/compile: don't emit reflect data for method types
authorMatthew Dempsky <mdempsky@google.com>
Fri, 25 Dec 2020 08:12:15 +0000 (00:12 -0800)
committerMatthew Dempsky <mdempsky@google.com>
Fri, 25 Dec 2020 11:15:22 +0000 (11:15 +0000)
commit1d9a1f67d537309f80740b16ef619500fb55db16
tree2583ffef454e022e2b59891af0c5a3d55ff2a89a
parent396b6c2e7c5c368c67e71824471d4f2d48f5c128
[dev.regabi] cmd/compile: don't emit reflect data for method types

Within the compiler, we represent the type of methods as a special
"method" type, where the receiver parameter type is kept separate from
the other parameters. This is convenient for operations like testing
whether a type implements an interface, where we want to ignore the
receiver type.

These method types don't properly exist within the Go language though:
there are only "function" types. E.g., method expressions (expressions
of the form Type.Method) are simply functions with the receiver
parameter prepended to the regular parameter list.

However, the compiler backend is currently a little sloppy in its
handling of these types, which results in temporary variables being
declared as having "method" type, which then end up in DWARF
data. This is probably harmless in practice, but it's still wrong.

The proper solution is to fix the backend code so that we use correct
types everywhere, and the next CL does exactly this. But as it fixes
the DWARF output, so it fails toolstash -cmp. So this prelim CL
bandages over the issue in a way that generates the same output as
that proper fix.

Change-Id: I37a127bc8365c3a79ce513bdb3cfccb945912762
Reviewed-on: https://go-review.googlesource.com/c/go/+/280293
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>
src/cmd/compile/internal/reflectdata/reflect.go