KSP is not thread safe in a multiplex worker environment

[Bencodes]

When using KSP in a persistent multiplexed worker environment we see unexplainable build errors claiming that KSP is unable to resolve types defined in the same module that's currently being processed. We believe this is happening because of the changed introduced here to avoid leaking memory, are now causing KSP to wipe out the resolver cached needed by other threads.

A few examples of the errors that we are seeing:

KSTypeReference#resolve returning null:

error: [ksp] java.lang.NullPointerException
        at com.google.devtools.ksp.symbol.impl.kotlin.KSTypeReferenceImpl.resolve(KSTypeReferenceImpl.kt:124)
        at com.lyft.ksp.skabbard.KspUtilsKt.resolveToUnderlying(KspUtils.kt:61)
        at com.lyft.ksp.skabbard.ClassOnlyTraversingResolver$getSymbolsWithAnnotation$1.invoke(ClassOnlyTraversingResolver.kt:37)
        at com.lyft.ksp.skabbard.ClassOnlyTraversingResolver$getSymbolsWithAnnotation$1.invoke(ClassOnlyTraversingResolver.kt:33)
        at kotlin.sequences.FilteringSequence$iterator$1.calcNext(Sequences.kt:171)
        at kotlin.sequences.FilteringSequence$iterator$1.hasNext(Sequences.kt:194)
        at kotlin.sequences.FilteringSequence$iterator$1.calcNext(Sequences.kt:169)
        at kotlin.sequences.FilteringSequence$iterator$1.hasNext(Sequences.kt:194)
        at kotlin.sequences.TransformingSequence$iterator$1.hasNext(Sequences.kt:214)

KSP is unable to resolve types defined in the same module that's being processed:

error: [ksp] java.lang.IllegalStateException: Cannot find package fragment com.lyft.android.scoop.unidirectional.interop
vFile = /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/execroot/instantandroid/instant-scoop/unidirectional/interop/src/main/java/com/lyft/android/scoop/unidirectional/interop/ScoopInteropGraph.kt, file package = 'com.lyft.android.scoop.unidirectional.interop'
        at org.jetbrains.kotlin.resolve.lazy.declarations.AbstractDeclarationProviderFactory.diagnoseMissingPackageFragment(AbstractDeclarationProviderFactory.java:51)
        at org.jetbrains.kotlin.resolve.lazy.ResolveSession.getPackageFragmentOrDiagnoseFailure(ResolveSession.java:275)
        at org.jetbrains.kotlin.resolve.lazy.LazyDeclarationResolver.getMemberScopeDeclaredIn$frontend(LazyDeclarationResolver.kt:223)
        at org.jetbrains.kotlin.resolve.lazy.LazyDeclarationResolver.findClassDescriptorIfAny(LazyDeclarationResolver.kt:71)
        at org.jetbrains.kotlin.resolve.lazy.LazyDeclarationResolver.getClassDescriptorIfAny(LazyDeclarationResolver.kt:59)
        at org.jetbrains.kotlin.resolve.lazy.LazyDeclarationResolver$resolveToDescriptor$1.visitClass(LazyDeclarationResolver.kt:100)
        at org.jetbrains.kotlin.resolve.lazy.LazyDeclarationResolver$resolveToDescriptor$1.visitClass(LazyDeclarationResolver.kt:94)

[ZacSweers]

This is a pretty bazel-specific use case, and the result of bazel running every KSP processor in its own thread rather than the cooperative round-based approach that KSP is implemented as. I don't see a path forward on this in the way it's currently implemented in rules_kotlin. Correct me if I'm misunderstanding @Bencodes

[ting-yuan]

KSP2 is implemented with thread-safty in mind.

The main thing prevents KSP1 from being thread-safe is class static variables like ResolverImpl.instance. There are a few solutions:

1. Passing them recursively down to each classes / methods that require them. Apparently this is a huge effort and given that KSP1's days are numbered, this isn't feasible.
2. Make those global variables thread local, but IIRC there was an attempt that eventually got reverted, I can't recall exactly but possibly because of processors that are multi-threading or performance issues.
3. Before calling KSP1 / compiler in the build system, give it a new classloader. Peformance-wise, this can be defeat the purpose of daemons. It should be fine if there's no daemons though.