Here's a minimal reproducer:

package p
func a(x struct { f int }) { _ = x.f }
func b() { a(struct { f int }{}) }

The issue is that the frontend doesn't guarantee uniqueness of types.Type instances for identical types; code has to use types.Identical for this. For example, in the code above the two struct { f int } type literals each get represented as their own types.Type instances.

Further, when inlining, we use the argument types to declare the inlined-parameter variables, but then copy the original AST nodes without re-typechecking them. When x.f was first typechecked, x referred to a variable with the first types.Type instance. But after substitution in inlining, it now refers to a variable of the second type. (To emphasize, the two instances both represent identical types, but they have separate pointer values.)

The field tracking code breaks because it uses the struct type instance as a map key, when this isn't strictly guaranteed to be unique. It worked up until cced777, I think because that CL seems to have had a side effect of changing the inlined-parameter variable's type from the types.Type instance used for the parameter to the one used for the argument. (f2c0c2b then allowed further inlining, which evidently led to the protobuf failure.)

I think the easiest fix is to simply get rid of the map, and use Node.Opt to store the *types.Field directly. I'll send a CL in the morning.

Change https://golang.org/cl/271217 mentions this issue: cmd/compile: fix panic in field tracking logic