Deduplicate extension config from ExtensionRegistrarConfigurator #32
Conversation
| FirExtensionRegistrarAdapter.registerExtension(SimplePluginRegistrar()) | ||
| IrGenerationExtension.registerExtension(SimpleIrGenerationExtension()) | ||
| } | ||
| ) = with(registrar) { registerExtensions(configuration) } |
There was a problem hiding this comment.
Hmm... I'm not sure how I feel about this specifically as a pattern to recommend. While I like and agree with the overall direction of deduplicating this registration logic, delegating directly to the registerExtensions member function of SimplePluginComponentRegistrar doesn't feel like the right choice. As an example, it's common for complex compiler plugins to have lots of custom directives to control various configuration options. There might also be test specific configuration to help debug failures.
I think we should follow the Kotlin Serialization pattern here and have a companion-level function to hold the logic. A companion-level extension function should work a little cleaner as well. And name it something like registerPlugin so we don't accidentally recurse.
There was a problem hiding this comment.
Looking at Metro's version, they prepare all these options from directives yes, but then ultimately pack it into a MetroOptions object, and the rest of the registration is almost the same logic as the normal registrar, except that they turn off the lookup tracker and expect-actual tracker. Their normal registration gets the same options thru the compiler configuration. Thus, I don't see why they couldn't just do it in configureCompilerConfiguration.
Similarly for the serialization plugin. They can add their singular option into configuration easily.
My point is that the normal registrar always gets its info from the configuration, so for tests, one should just put the necessary info into configuration, and then call registerExtensions.
In some sense, parsing directives into the compiler configuration is the same idea as parsing cli options into the compiler configuration.
Btw, there's no fear of accidental recursion since this method is called registerCompilerExtensions and the normal one is registerExtensions.
2 participants
This is important for more complex plugins that share state between FIR and IR; also important for plugins that extract info from the compiler configuration.