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
Beginning with KSP 2.1.0-1.0.28, we began observing that, after making a change to a project dependency and recompiling, our KSP processor would receive no input files (resolver.getAllFiles() is empty) and thus fail to generate the expected output.
After cleaning the project and rebuilding, the correct inputs are passed to the KSP processor and the project builds as expected.
Some observations I made while investigating the issue:
Disabling KSP incremental processing with ksp.incremental=false fixes the issue, even though the processor uses Dependencies.ALL_FILES
The issue does not occur for the JS target with KSP 2.0.21-1.0.28 but does occur with KSP 2.1.0-1.0.28. On the JVM target, it has been present for longer
Enabling KSP2 resolves the issue for the JS target but not for the JVM target
Similarly, disabling non packed Klibs with the flag kotlin.internal.klibs.non-packed=false resolves the issue for the JS target but not for the JVM target
This may be a duplicate of #1694, though that issue references a JVM only project.
The text was updated successfully, but these errors were encountered:
Beginning with KSP 2.1.0-1.0.28, we began observing that, after making a change to a project dependency and recompiling, our KSP processor would receive no input files (
resolver.getAllFiles()
is empty) and thus fail to generate the expected output.After cleaning the project and rebuilding, the correct inputs are passed to the KSP processor and the project builds as expected.
Repro Steps
And then follow the instructions in the README
Other observations
Some observations I made while investigating the issue:
ksp.incremental=false
fixes the issue, even though the processor usesDependencies.ALL_FILES
kotlin.internal.klibs.non-packed=false
resolves the issue for the JS target but not for the JVM targetThis may be a duplicate of #1694, though that issue references a JVM only project.
The text was updated successfully, but these errors were encountered: