kotlin: make incremental compilation actually engage

[oyvindberg]

Kotlin incremental compilation has never engaged, in any configuration bleep ships. Every Kotlin build is a full compile, and nothing says so.

Independent of the Windows/CI work — touches only KotlinSourceCompiler and its test.

Three independent bugs, each fatal on its own

1. Wrong runner class. compileIncremental looked for a 7- or 6-arg IncrementalJvmCompilerRunner. Actual declared arities (javap -p on the real jars):

Kotlin	ctor arity	7-arg	6-arg
2.0.0, 2.1.20	9 (+11 synthetic)	✗	✗
2.2.0, 2.3.0	6 (+8)	✗	✓
2.3.21	9 (+11)	✗	✗

And on 2.2+ that class only supports the classpath-snapshot path — it hard-errors with Unexpected ClasspathSnapshotDisabled for this code path on the ClasspathSnapshotDisabled we pass. The class we actually wanted is BuildHistoryJvmICRunner (the build-history runner, what Maven uses), whose 7-arg signature is what the old code was half-remembering — except slot 5 is a ModulesApiHistory, not a ClasspathChanges.

2. ChangedFiles.Unknown. IncrementalCompilerRunner.compile returns RequiresRebuild on it immediately, before looking at anything, and compileNonIncrementally then calls cleanOrCreateDirectories on the output dir. Full compile, every build, even on the versions where the constructor matched.

3. incrementalCompilation never set. JvmConfigurationPipelinePhase.setupIncrementalCompilationServices returns early unless it is on, so the LookupTracker / ICFileMappingTracker / IncrementalCompilationComponents handed over via Services are dropped, no output→source mappings come back, and caches-jvm/jvm/kotlin/ is never written — leaving the next build nothing to be incremental against.

Plus a fourth: classpath-hash lived inside .kotlin-ic, which is passed to Kotlin as one of outputDirs and therefore wiped by cleanOrCreateDirectories on rebuilds. Cross-language change detection was erasing its own state.

Changes

• Use BuildHistoryJvmICRunner + EmptyModulesApiHistory.INSTANCE via its 7-arg constructor; dropped the 6-arg attempt.
• Pass ChangedFiles.DeterminableFiles.ToBeComputed.INSTANCE — the runner diffs sources itself against caches-jvm/inputs/source-snapshot.tab (content hash + length, not mtime, so bleep rewriting sources on every compile is harmless here).
• Set args.incrementalCompilation = true. Deliberately the compiler argument rather than the JVM-global kotlin.incremental.compilation system property, since this runs in a daemon shared across workspaces.
• Move classpath-hash to a sibling <outputDir>.kotlin-ic-meta/.
• Both fallbacks now print to stderr instead of a debug() gated on bleep.kotlin.debug, which is set nowhere in the tree — that gate is why this was invisible.

Version support

BuildHistoryJvmICRunner exists from Kotlin 2.2.0. Below that we warn once and compile non-incrementally — same behaviour as today, now visible. bleep-test-ksp-processor pins 2.1.20 and takes that path.

Follow-up, not in this PR: Versions.Kotlin21 = "2.1.21" is the default when a project omits kotlin.version, so unpinned projects get no IC. Kotlin23 = "2.3.21" (what bleep build create-new writes) is fine.

Verification

New regression test asserts caches-jvm/jvm/kotlin/class-fq-name-to-source.tab and source-to-classes.tab exist after a compile, and that a marker file in the output dir survives a second round — a rebuild wipes it, only the incremental path leaves it. Confirmed it fails without the fix (stashed the compiler change, re-ran, red; restored, green).

Run against this exact base:

suite
IncrementalTrackingTest (incl. new test)	6 passed
IncrementalCompilationTest — change A → break A → fix A, per language	3 passed
CompilerVersionIsolationTest — Kotlin 2.3.0 + 2.2.0, mixed Java/Kotlin	12 passed
CompilerIntegrationTest	7 passed
ClasspathCompilationTest	3 passed
SymbolProcessorDagIntegrationTest (KSP)	7 passed
CancellationTest / PlatformCancellationTest	14 passed

The change/break/fix suite is the one that matters — that is where a wrong IC setup yields stale classes rather than an error.

Caveat: these all drive the compiler in-process. The deployed path (a bleep binary against a forked daemon) still wants a bleep sourcegen && bleep publish local-ivy smoke test.

🤖 Generated with Claude Code