You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was originally reported in isaac-udy/Enro, but I believe that this is an issue with Hilt (not with Enro). The original issue is here: isaac-udy/Enro#192
Problem:
It appears that when Hilt is used with KSP and another KSP processor causes multiple rounds of processing, Hilt will attempt to recreate files such as the Activity/Fragment _GeneratedInjector.java files. This causes a FileAlreadyExistsException for each of the classes that Hilt attempts to recreate, causing the KSP processing build step to fail.
Expected behavior:
When another KSP processor causes multiple rounds of processing, Hilt should not attempt to generate files multiple times.
Example stacktrace:
[ksp] [Hilt] [ksp] [Hilt] ...\example\build\generated\ksp\debug\java\byRounds\2\dev\enro\example\MainActivity_GeneratedInjector.java: kotlin.io.FileAlreadyExistsException: ...\example\build\generated\ksp\debug\java\byRounds\2\dev\enro\example\MainActivity_GeneratedInjector.java
at com.google.devtools.ksp.processing.impl.CodeGeneratorImpl.createNewFile(CodeGeneratorImpl.kt:116)
at com.google.devtools.ksp.processing.impl.CodeGeneratorImpl.createNewFile(CodeGeneratorImpl.kt:67)
at dagger.spi.shaded.androidx.room.compiler.processing.ksp.KspFiler.createNewFile(KspFiler.kt:156)
at dagger.spi.shaded.androidx.room.compiler.processing.ksp.KspFiler.write(KspFiler.kt:46)
at dagger.hilt.android.processor.internal.androidentrypoint.InjectorEntryPointGenerator.generate(InjectorEntryPointGenerator.java:69)
at dagger.hilt.android.processor.internal.androidentrypoint.AndroidEntryPointProcessingStep.processEach(AndroidEntryPointProcessingStep.java:54)
at dagger.hilt.processor.internal.BaseProcessingStep.process(BaseProcessingStep.java:118)
at dagger.hilt.android.processor.internal.androidentrypoint.AndroidEntryPointProcessingStep.process(AndroidEntryPointProcessingStep.java:35)
at dagger.spi.shaded.androidx.room.compiler.processing.CommonProcessorDelegate.processRound(XBasicAnnotationProcessor.kt:130)
at dagger.spi.shaded.androidx.room.compiler.processing.ksp.KspBasicAnnotationProcessor.process(KspBasicAnnotationProcessor.kt:62)
at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension$doAnalysis$8$1.invoke(KotlinSymbolProcessingExtension.kt:305)
at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension$doAnalysis$8$1.invoke(KotlinSymbolProcessingExtension.kt:303)
at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.handleException(KotlinSymbolProcessingExtension.kt:409)
at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.doAnalysis(KotlinSymbolProcessingExtension.kt:303)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:112)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:88)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:256)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:42)
at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:115)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:247)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:181)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:87)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli$default(KotlinToJVMBytecodeCompiler.kt:47)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:168)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:53)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:100)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:46)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:101)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1497)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
The text was updated successfully, but these errors were encountered:
This was originally reported in
isaac-udy/Enro
, but I believe that this is an issue with Hilt (not with Enro). The original issue is here: isaac-udy/Enro#192Problem:
It appears that when Hilt is used with KSP and another KSP processor causes multiple rounds of processing, Hilt will attempt to recreate files such as the Activity/Fragment
_GeneratedInjector.java
files. This causes aFileAlreadyExistsException
for each of the classes that Hilt attempts to recreate, causing the KSP processing build step to fail.Expected behavior:
When another KSP processor causes multiple rounds of processing, Hilt should not attempt to generate files multiple times.
Example stacktrace:
The text was updated successfully, but these errors were encountered: