Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2.5.0-beta05 breaks custom code generators #953

Open
SteinerOk opened this issue Apr 9, 2024 · 2 comments
Open

v2.5.0-beta05 breaks custom code generators #953

SteinerOk opened this issue Apr 9, 2024 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@SteinerOk
Copy link

My project uses custom generators, which worked fine before updating to the version v2.5.0-beta05.
After the update, some of them stopped working.

I conducted an analysis and discovered the following pattern:
Generators that require annotated classes MergeSubcomponent (check via isAnnotatedWith(FqNames.mergeSubcomponent)) do not generate the required code.

In my code, I use ContributesSubcomponent in the base module and rely on the presence of generated classes with the MergeSubcomponent annotation in the application module, but it seems that custom generators are no longer called for the generated classes with annotation MergeSubcomponent.

To play repo: https://github.com/SteinerOk/sealant/tree/ik/sample

@RBusarow RBusarow self-assigned this Apr 9, 2024
@RBusarow RBusarow added the bug Something isn't working label Apr 9, 2024
@RBusarow
Copy link
Member

Thanks for the (extremely quick) report!

For reference, the generator that creates the @MergeSubcomponent interfaces is called ContributesSubcomponentHandlerGenerator.

The problem is one of sequencing. The ContributesSubcomponentHandlerGenerator is invoked after your custom generators have already finished. That change is new.

Prior to beta05, the ContributesSubcomponentHandlerGenerator was invoked in a batch with most of the other generators - including any custom ones. It was invoked last, but that entire batch of generators is invoked in a loop, so anything it generates is seen by the other generators in the subsequent loop. The problem with this approach was that the custom generators can also be generating @ContributesSubcomponent interfaces, where those new interfaces replace existing ones.

In your use-case, you're depending upon what is effectively an internal API. Are you able to get the information you need (the scope?) from something else upstream?

@SteinerOk
Copy link
Author

@RBusarow Good evening, sorry for the wait.

Thanks for the clarification, I understand why this is happening now.

But, unfortunately, I don’t know what to do now, because this change breaks many of my code generators: in my main project the structure of subcomponents is described in the DI module (as light as possible with a minimum of dependencies), and the root component (skeleton component) in the application module, in which integrations for everything are already generated.
This happens thanks to the annotation @ContributesSubcomponent for subcomponents and the use of generated components with annotation @MergeSubcomponent in custom generators

And so it turns out that the benefits of the annotation@ContributesSubcomponent are lost after these changes.

Maybe you can suggest something if this is not a bug but a feature?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants