Giter Club home page Giter Club logo

Comments (11)

MasaHirano avatar MasaHirano commented on June 9, 2024 3

Dear @bcorso,

I am also facing this issue. In my case, the issue happens when I modify an Activity file that hosts fragments. I created a sample project where I can reproduce it on my end.
https://github.com/alpaca0984/DaggerKspIssueRepro

I hope it helps the investigation.

from dagger.

wanyingd1996 avatar wanyingd1996 commented on June 9, 2024 2

I tried patching the repro, and can consistently reproduce the issue with dagger 2.50. But the issue seems to be gone with dagger at head. So next release should fix this problem.

from dagger.

mackenzie-powers-mahana avatar mackenzie-powers-mahana commented on June 9, 2024 1

I'm also having this issue with an app using Circuit and its associated codegen artifacts; I'll try to create a simple project to reproduce the issue.

from dagger.

palpapp04 avatar palpapp04 commented on June 9, 2024 1

That might be tricky because to me it is happening with pretty large commercial app but I will try to reproduce this with a sample project over the weekend by isolating a module where the stack trace points to and deleting everything that's irrelevant (no promises though 😄). I also have a smaller project but that does not uses @ContributesAndroidInjector and there KSP works as expected so that's definitely needed to reproduce this bug.

from dagger.

MaratTursynbek avatar MaratTursynbek commented on June 9, 2024 1

I'm also experiencing this. In addition to the author's description, despite second build being successful, it takes way longer to build and run than it was before. It feels like there is no incremental build and full clean rebuild is happening. Changing even one line of kotlin code makes it 5 minutes to run in the emulator. Before it would take me less than 10 sec to get latest code into the running app. XML code changes work fine - runs on 1st attempt and fast compilation times as before.

I also tried with AGP 8.2.1 and kotlin 1.9.22 with ksp 1.9.22-1.0.16 and the problem is still there.

from dagger.

wanyingd1996 avatar wanyingd1996 commented on June 9, 2024 1

Hi, I was able to repro the problem at head, not sure why couldn't repro earlier. It seems to be a ksp bug where the cached generated source file wasn't discoverable by the processor. I'm working with ksp team on this issue now, will follow up once made progress. Thanks for the patience!

from dagger.

palpapp04 avatar palpapp04 commented on June 9, 2024 1

@wanyingd1996 Thank you for the fix on this issue. I just upgraded my project to the latest dagger version and for me the issue still persist however I am getting a different exception than before saying that a generated file already exists. I saw that there is a similar issue #4161 but in my project I do not use hilt and I still get this exception. After building again the issue disappears just like before. Here is my stack trace, I would appreciate if you would take a look and let me know if I should open a new issue for this one.

Thanks in advance.

java.nio.file.FileAlreadyExistsException: ~\build\generated\ksp\*******Debug\java\com\***\***\***\***\***\*******_Factory.java
	at java.base/sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:124)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:284)
	at java.base/java.nio.file.Files.copy(Files.java:1305)
	at com.google.devtools.ksp.common.IncrementalUtilKt.copyWithTimestamp(IncrementalUtil.kt:80)
	at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.updateFromShadow(KotlinSymbolProcessingExtension.kt:477)
	at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.doAnalysis(KotlinSymbolProcessingExtension.kt:375)
	at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:112)
	at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:77)
	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:247)
	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.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:43)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:165)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:50)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:104)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:48)
	at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:101)
	at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1523)
	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:840)

from dagger.

wanyingd1996 avatar wanyingd1996 commented on June 9, 2024 1

Hi, @palpapp04, from the stack trace you provided, nothing points to dagger or hilt, it seems a bug from ksp side during incremental processing that fails to handle generated file. It is different from #4161, as that bug happens when hilt is trying to write file. So I think you may want to try bump your ksp version first, if it still fails, file a bug to the ksp issue.

from dagger.

palpapp04 avatar palpapp04 commented on June 9, 2024

I am also experiencing this problem (just commenting to raise awareness of this one)

from dagger.

bcorso avatar bcorso commented on June 9, 2024

Thanks, if you can provide a project reproducing this that would help a lot.

from dagger.

palpapp04 avatar palpapp04 commented on June 9, 2024

@wanyingd1996 I just tried it out after the release of Dagger 2.51 and I am still seeing this problem unfortunately

from dagger.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.