multiple-round: implement incremental providers #1494
Conversation
and replace StandaloneAnalysisAPISessionBuilder, which hides KotlinCoreProjectEnvironment, which is needed to update KotlinCliJavaFileManagerImpl for new files.
ting-yuan
force-pushed
the
aa-multiple-round
branch
from
a0ec509
to
ddc179b
Compare
Also, do not create processors repeatedly in each round.
|
|
||
| override fun toResult(): List<String> { | ||
| return visitor.toResult() | ||
| return result |
There was a problem hiding this comment.
Some KtSymbols are not available after cache drop
| import org.jetbrains.kotlin.psi.KtScript | ||
| import org.jetbrains.kotlin.psi.KtTypeAlias | ||
|
|
||
| class IncrementalKotlinDeclarationProvider(var del: KotlinDeclarationProvider) : KotlinDeclarationProvider() { |
There was a problem hiding this comment.
if we are purely delegating here, it might make more sense to simply use delegation without need to write down all the redundant overrides here.
There was a problem hiding this comment.
Unfortunately, by delegation doesn't allow swapping the delegate.
| lateinit var processors: List<SymbolProcessor> | ||
| lateinit var newKSFiles: List<KSFile> | ||
| lateinit var newFileNames: Set<String> | ||
| while (!finished) { |
There was a problem hiding this comment.
are we falling back to the previous design for multiple round processing? Just want to know if this conflicts with the plan to do multiple round within Gradle runner.
There was a problem hiding this comment.
IIRC the plan is to do it here, in the unified entry point of production and test. There will be multilple callers in addition to gradle and we want the setup to be as easy as possible.
and replace StandaloneAnalysisAPISessionBuilder, which hides KotlinCoreProjectEnvironment, which is needed to update KotlinCliJavaFileManagerImpl for new files.