I’m having an issue with incremental compilation. ...

# ksp

[elihart]

I’m having an issue with incremental compilation. I’ve read the docs and used ksp.incremental.log=true (very helpful, btw!) so I think I understand what is going on.

My generated file (aggregating) relies on both a symbol in sources acquired with getSymbolsWithAnnotation and a set of classes on the classpath (via getDeclarationsFromPackage). The file’s originating elements reflect this, as do the ksp incremental logs, so the dependencies seem correctly understood by KSP.

My problem is that when there are classpath changes and the processor incrementally runs, KSP sees that only the classpath files changed and does not consider my source file as dirty, so my call to getSymbolsWithAnnotation does not return anything. This is problematic because I need both the symbol in source as well as the classpath files to generate my output file, and this fails when I cannot get the source symbol with getSymbolsWithAnnotation .

I understand why KSP does this, and it is optimal for some cases, but it makes generating a file that depends on both sources and classpath difficult - I think I would have to work around this by manually getting all files and parsing them.

Would it be reasonable instead for KSP to look at the set of inputs to a generated file, and if any one of those input is a classpath change then consider the rest of the inputs as dirty as well? according to the docs this is already done with sources, but maybe not for classpath changes?

Propagation by input-output correspondence: If a source file is changed or affected, all other source files having some output in common with that file are affected.

[Ting-Yuan Huang]

That sounds like a bug. Let me take a look

[Ting-Yuan Huang]

When calling createNewFile, what's the dependencies (list of KSFile) passed in to account for getDeclarationsFromPackage? Or do you mean this is the workaround you would do?

[elihart]

that’s not the workaround I was referring to - for that I was thinking of Resolver.getAllFiles and manually visiting all of them.

But to answer your question, for createNewFile I believe for the classpath dependencies I use the KSClassDeclaration from getDeclarationsFromPackage and pass the KSClassDeclaration.containingFile (it’s done through XProcessing)

In the kspSourceToOutputs.log it shows the source name as <AnyChanges is a virtual file; DO NOT USE.>:

[Ting-Yuan Huang]

containingFile is always null for classes from classpath. We may need some addition in the API to account for changes from classpath.

[Ting-Yuan Huang]

AnyChanges is a placeholder for propagating dirtiness for sources of aggregating outputs. We can use it to fix the issue here, only for aggregating outputs.

[Ting-Yuan Huang]

something like associate(decl: KSDeclaration)

[elihart]

ok, that would be great, appreciate you looking into it

[Ting-Yuan Huang]

Here is the tracking issue. We'll try to fix it asap.
https://github.com/google/ksp/issues/630

[yigit]

I wonder if we could hash the ".class" file so that it stays granular?

[Ting-Yuan Huang]

I'm trying to see whether we can synthesize containing file for classes, but worried that could break compatibility. API won't change, but behavior will.

[Ting-Yuan Huang]

That should be able to keep the granularity

[elihart]

thanks for the fix (https://github.com/google/ksp/pull/686). any idea when we can expect a release with this?

Once it’s out I think I’ll need to make a small change to XProcessing to support it

[Ting-Yuan Huang]

We'll do a 1.0.1 RC release with Kotlin 1.6.0 RC in the coming week. The formal release will come with Kotlin 1.6.0, which shouldn't be too far away. Does that work for you?

[elihart]

yes, thank you!

[elihart]

@yigit I suppose I’ll then be blocked on how quickly androidx/room update to Kotlin 1.6.0 and KSP 1.0.1. I’m happy to make the change for associateWithClasses in XProcessing but the Kotlin update seems harder

[yigit]

Compose very quickly updates as soon as stable is out (they usually have a cl with rcs).
The harder question is which room release we can catch but I think you can use snapshots meanwhile?

[yigit]

Btw, Android X has 1 kotlin version policy so compose update includes ksp update

[elihart]

ah, good to know about compose. sounds like that should happen quick enough.

we can use snapshots if the room release will be a while