Implement the PkgPath() method on reflect.Type

[kyleconroy]

Code generated by protoc-gen-go includes a init function like this in each file.

func init() { file_plugin_codegen_proto_init() }
func file_plugin_codegen_proto_init() {
	type x struct{}
	out := protoimpl.TypeBuilder{
		File: protoimpl.DescBuilder{
			GoPackagePath: reflect.TypeOf(x{}).PkgPath(),
			RawDescriptor: file_plugin_codegen_proto_rawDesc,
			NumEnums:      0,
			NumMessages:   21,
			NumExtensions: 0,
			NumServices:   0,
		},
		GoTypes:           file_plugin_codegen_proto_goTypes,
		DependencyIndexes: file_plugin_codegen_proto_depIdxs,
		MessageInfos:      file_plugin_codegen_proto_msgTypes,
	}.Build()
	File_plugin_codegen_proto = out.File
	file_plugin_codegen_proto_rawDesc = nil
	file_plugin_codegen_proto_goTypes = nil
	file_plugin_codegen_proto_depIdxs = nil
}

This code fails to run on the current dev branch of TinyGo, as PkgPath() is not implemented for reflect.Type:

func (t rawType) PkgPath() string {
	panic("unimplemented: (reflect.Type).PkgPath()")
}

Required by #2667

[kyleconroy]

@skabbes any ideas for implementing this one?

[skabbes]

High level: I think we need to store a "sidetable" of typecode -> PkgPath mapping, and then reference that sidetable at runtime. The implementation of struct names reflection seems to already do this exact same technique, so there is a little bit of example code to follow along here. The difference between them I think is that the package information is erased by the time it is in the LLVM IR. So, I think some of the method signatures are going to have to change (we'll have to pass along the struct that represents the Go Package most likely, since - so we can reassociate each [Go] type with its package).

Code Overview (my best understanding after reading a bit)

1. The reflection code is written (in Go) assuming the sidetables will be populated sometime before runtime (which is why it is marked extern, and using the unsafe package).
2. Each package of Go code is compiled to LLVM Modules.
3. An optimization pass is done on the LLVM IR
4. As part of this pass, the reflection sidetables are populated. But as you see in the code, they are only generated if they are ever referenced. This means if your Go program does not use reflection, do you not pay the price of these sidetables. This seems to go along with the TinyGo philosophy, so I think that same level of optimization will need to be applied to PkgPath too.

So, I don't think this is trivial - but, its not impossible either. Though some function signatures I think are going to need to change in the internals, so it might be a disruptive change. Perhaps a first step is to refactor to decouple "optimize" from "populate runtime type information side-tables".

[dearchap]

@kyleconroy Great talk here at #GopherCon . What I would suggest, for the time being, is to replace the

GoPackagePath: reflect.TypeOf(x{}).PkgPath() 

with a hand crafted value so that you can move along. Maybe your build system can do a search replace on these before compiling. That seems much easy that digging into the entire LLVM IR

[dgryski]

PkgPath has been implemented here: #3498

[deadprogram]

This is part of the v0.28 release so now closing this issue. Thanks!