mirror of
https://github.com/golang/go
synced 2024-09-15 22:20:06 +00:00
[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>
This commit is contained in:
parent
396b6c2e7c
commit
1d9a1f67d5
|
@ -835,6 +835,10 @@ func TypeSym(t *types.Type) *types.Sym {
|
|||
if t == nil || (t.IsPtr() && t.Elem() == nil) || t.IsUntyped() {
|
||||
base.Fatalf("typenamesym %v", t)
|
||||
}
|
||||
if t.Kind() == types.TFUNC && t.Recv() != nil {
|
||||
// TODO(mdempsky): Fix callers and make fatal.
|
||||
t = typecheck.NewMethodType(t, t.Recv().Type)
|
||||
}
|
||||
s := types.TypeSym(t)
|
||||
signatmu.Lock()
|
||||
NeedRuntimeType(t)
|
||||
|
|
Loading…
Reference in a new issue