Support expect / actual for generated factory functions using @CreateComponent
#62
Conversation
|
Nice! I don't like the ext-fun on Personally I'd prefer something like: @GenerateActualAccessors
expect fun createAppComponent(foo: String): AppComponent...but it's not a blocker. The |
After thinking about it more over the weekend, I fully agree with all your points. I'll introduce I'll do this as a follow up. Any suggestions for the name? |
|
I updated this PR and introduced |
vRallev
changed the title
expect / actual for generated factory functionexpect / actual for generated factory functions using @CreateComponent
|
Nice! |
|
|
||
| private val kclassFqName = KClass::class.requireQualifiedName() | ||
|
|
||
| @Suppress("ReturnCount") |
| // https://github.com/ZacSweers/kotlin-compile-testing/issues/298 | ||
| // | ||
| // The correctness is verified through the sample app of this project for now. | ||
| class CreateComponentProcessorTest { |
There was a problem hiding this comment.
Can we check the successful path? Or is there no real way to do that with expect / actual?
There was a problem hiding this comment.
No, not right now, because the compiler will pick up all generated files and then complain about that these keywords cannot be used within the same module / source set. It's a limitation of the compile testing library right now. We should help and add support for this.
…ateComponent` Due to how Kotlin 2.0 and newer handles source sets, it's likely that the generated factory function for generated components cannot be referenced from common Kotlin code in KMP projects. This change adds a new annotation `@MergeComponent.CreateComponent` to allow defining an `expect fun` in common code where the `actual fun` will be generated. This closes the gap. Fixes #20
Due to how Kotlin 2.0 and newer handles source sets, it's likely that the generated factory function for generated components cannot be referenced from common Kotlin code in KMP projects. This change adds a new annotation
@MergeComponent.CreateComponentto allow defining anexpect funin common code where theactual funwill be generated. This closes the gap.Fixes #20