Generated code is not reproducible when multiple plugins are specified

[ashi009]

So far this is not a problem, as there is only one plugin built in to protoc-gen-go. However when more than one plugin is registered the generator may behave unexpectedly.

This is caused by two issues:

1. RegisterPlugin is called from init() and the execution sequence is not guaranteed (though it's possible to manually control the import sequence and hope go doesn't change it's behavior on handling import packages).
2. Registered plugins are filtered against the list of plugin to use from user input at runtime. Meaning, the order of plugins to use doesn't affect the final output -- it will always be unpredictable. What makes things worse is that, unknown plugin will be ignored silently.

I think the second place is the best place to fix this issue.

[dsnet]

The Go language spec specifies that package initialization occurs in declaration order. Given that, I don't really see an issue.

[ashi009]

You are right about that. I should have made it more clear about the problem here. As the plugins are registered as side effect of importing a package, so the import sequence matters. Although govet checks if all the side effect imports are in main package, there is no way to guarantee that a plug-in is only imported in main. As it’s possible that a plug-in package is imported by another package for using one of its method and in that case the plug-in will be registered in an undetermined order. Even if we can assume that all these plug-ins are only imported from main only, controlling the output sequence with import order is not clear. Especially that the packages are always sorted with gofmt unless additional empty lines are inserted around all the plug-in imports. IMHO the issue still exists and needs to be fixed. Joe Tsai <[email protected]>于2017年12月15日 周五上午2:56写道：

…

The Go language spec specifies that package initialization occurs in declaration order <https://golang.org/ref/spec#Package_initialization>. Given that, I don't really see an issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#474 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAp9B6bQEHhCpbe6GkEnCr-Smk8uIWlSks5tAW91gaJpZM4RB_F5> .

[dsnet]

The generator plugin API is something that could use an overhaul. We probably don't have time to think about it today, but will keep this issue in mind for the future.

[paranoiacblack]

@ashi009 Can you provide any motivating examples where this problem shows up? It seems like it needs to be up to each plugin to directly specify which stage of plugin initialization it belongs to. If that were the case, we could lazily register plugins. There's probably no way the Go tool or the compiler will be able to deduce this, although package initialization order is really close.

[dsnet]

At the present time, we want to hold to a harder stance that 3rd party plugins added via generator.RegisterPlugin are not well supported. It is very difficult making changes to protoc-gen-go without breaking any arbitrary registered plugin. The best path forward would be to just fork generator for your own purposes.

[dsnet]

Filed #547 as an umbrella for better plugin support.

[ashi009]

Cheers

…

On Thu, Mar 8, 2018 at 10:07 AM Joe Tsai ***@***.***> wrote: Filed #547 <#547> as an umbrella for better plugin support. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#474 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAp9B4F5tCy4-z_Bd7pa2EdBplNUVJegks5tcJJMgaJpZM4RB_F5> .