dagger: ComponentProcessingStep was unable to process 'Component' with Kotlin 1.7.0
Similar to this but I dont use Hilt. Downgrading to Kotlin 1.6.21 works. I also use compose (compiler 1.2.0 for Kotlin 1.7.0, otherwise 1.2.0-rc02).
ComponentProcessingStep was unable to process 'progression.phone.main.PhoneComponent' because 'progression.presentation.training.replace.ReplaceTrainingController' could not be resolved.
If type 'progression.presentation.training.replace.ReplaceTrainingController' is a generated type, check above for compilation errors that may have prevented the type from being generated. Otherwise, ensure that type 'progression.presentation.training.replace.ReplaceTrainingController' is on your classpath.
The file is included in my classpath and is injected as follows:
class ReplaceTrainingController @Inject constructor(...)
class OtherController @Inject constructor(
private val replaceTrainingController
)
kotlin = ‘1.7.0’ compose-compiler = ‘1.2.0’ gradle = ‘7.4.0-alpha07’ dagger = ‘2.42’
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 6
- Comments: 33
As a follow-up to the above, I was able to recreate it in a very controlled project. I suspected still that the problem was with kapt and not Dagger, so I also tried it with a small / custom annotation processor.
I can confirm that Dagger isn’t the problem in my case - and instead with the fact that generated classes aren’t appearing on the kapt classpath in Kotlin 1.7
Here’s a reproduction of it: https://github.com/malbanese/kotlin-1-7-kapt-bug
We see a similar issue when updating to Kotlin 1.7.0I think it’s worth to mention that the classes which can’t be found are within a pure Kotlin module (no android module)I tested it and migrated the module to an android module and it has the same effect.
@s0nicyouth, can you give an example usage?
For example, if the Gson type is exposed as the return type of an
@Providesmethod then technically it is used bymodule1when processing the Dagger component since we need all referenced classes to be on the classpath to do our validation properly. This was recently changed in the 2.40.x releases, so going forwardmodule1would need a dependency ongson(or equivalently,module2can declare anapidependency ongson) in order for us to ensure proper validation of types.Setting
correctErrorTypes = truehas also fixed “error: cannot find symbol NonExistentClass” that appeared with a Hilt module and updating the project to Kotlin 1.7Hi, @malbanese , thanks for the repro! This looks like the same issue as what @hoc081098 got, and now we know it’s not limited to ProtoBuf. We believe JetBrains is looking at it: https://youtrack.jetbrains.com/issue/KT-52761/Kotlin-170-breaks-kapt-processing-for-protobuf-generated-java-sources
Hi, @zoltish Do you also have any other code generation in your project? If so, this could be the same issue as @malbanese and @hoc081098 saw. You can also try enabling correctErrorTypes or force kotlin-metadata-jvm to a newer version.
@jannisveerkamp Could you please mention this in the issue? The fixes are included in 1.7.20-RC, so kind of worrying to hear that its still happening for you. Im pretty sure Id be seeing the same thing if I was able to upgrade to 1.7.20-RC as well (a couple of libraries are blocking me from doing so atm).
After some digging I could actually solve the issue:
The classes that couldn’t be found were inline classes like this:
Removing
@JvmInlineandvaluefixed the problem.Hey @kuanyingchou!
No other code generation, I tried forcing metatadata to a newer version before posting this issue and it had no effect. Ill try correctErrorTypes, probably after the weekend though.
They work completely fine using 2.42 and 1.6.21! I can switch between 1.6.21/1.7.0 and see it break like this 🥲