Incremental compilation: getNewFiles inconsistent behavior on Linux vs Mac.

[vnermolaev]

Hi,

I and my colleagues develop a KSP-based processor that makes use of incremental compilation.
The logic is as follows:

class MyProcessor(
    private val environment: SymbolProcessorEnvironment
) : SymbolProcessor {
    var i = 0
   
    override fun process(resolver: Resolver): List<KSAnnotated> {
        println("[$i] Handling NEW: ${resolver.getNewFiles().joinToString { it.toString() }}")
        println("[$i] Handling ALL: ${resolver.getAllFiles().joinToString { it.toString() }}")
        i++

        resolver.getNewFiles()
            .forEachIndexed { idx, file ->  
                // logic approximately boils down to
                // if i == 0 generate new file with name `NewFile_idx.kt` 
            }
            
        return emptyList()
    }
}

If the snippet is run on Debian/Ubuntu, the following output is generated

[0] Handling NEW: File: MyFile.kt
[0] Handling ALL: File: MyFile.kt
[1] Handling NEW: File: NewFile_0.kt
[1] Handling ALL: File: MyFile.kt, File: NewFile_0.kt
[2] Handling NEW: 
[2] Handling ALL: File: MyFile.kt, File: NewFile_0.kt

If the snippet is run on Mac, the following output is generated

[0] Handling NEW: File: MyFile.kt
[0] Handling ALL: File: MyFile.kt
[1] Handling NEW: File: 
[1] Handling ALL: File: MyFile.kt, File: NewFile_0.kt

which is clearly inconsistent.

Any advices on what can trigger such a behavior?

[ting-yuan]

@vnermolaev Could you print the filePath of the files?

I suspect that this is a bug related to how KSP computes the set of new files. KSP tracks generated files in File.canonicalPath, but compares to PsiFile.virtualFilePath.

cc @neetopia

[ting-yuan]

@vnermolaev The possible fix is now available in the just released KSP 1.6.10-1.0.3. Hope that fixes this issue and if not, please let me know.