Hi, we just made a release at <https://github.com/google/ksp/releases/tag/1.4.10-dev-experimental-20...

# ksp

[Jiaxiang]

Hi, we just made a release at https://github.com/google/ksp/releases/tag/1.4.10-dev-experimental-20201106
Highlights
• KSP is now in a separate task from the main kotlinCompile task, which allows you to run ksp alone.
• Now you can generate class files to be included in kotlin compile.
• Now you can write test in KSP repo for multiple module use cases, good for testing dependency related issue. (Credit to @yigit !)
• As a prerequisites of KSP multiple round processing, we added a symbol validation API for validating types in a symbol’s enclosed scope. See KSNode.validate() for more details.

[Zac Sweers]

I'm unable to get KSP to run via gradle alone, it seems to completely miss appropriate wiring and never gets run even if I run the ksp task directly. Did any project structure requirements change?

[Zac Sweers]

repro is https://github.com/ZacSweers/MoshiX, running ./gradlew :moshi-ksp:tests:test no longer appears to run KSP and generate any subsequent code

[evant]

running into the same thing, tried updating ksp and now no code is generated

[Zac Sweers]

quick update, reverted the update on my repo, use this link https://github.com/ZacSweers/MoshiX/tree/324c8e03f2f61d3b4a0953687d5706968a35954b

[Jiaxiang]

Thanks for reporting.. I’ll file a bug for tracking

[Ting-Yuan Huang]

Somehow the dependency in ksp(....) is missing and therefore the processor might not be ready when needed. A temporary workaround would be appending compileOnly(...) along with ksp(). I'm still investigating why it is missing.

[Zac Sweers]

I'll give that a shot

[Ting-Yuan Huang]

Thanks. I have a patch ready and will make another release tomorrow.

[Jacob Applin]

What is the benefit of moving KSP to a seperate task?

[Zac Sweers]

I'm curious as well, seems to sort of go against the original goal of running as a compiler plugin in the same compilation. A big part of why kapt is slow is because it's a separate task and thus a separate (even if faster) compilation

[Ting-Yuan Huang]

The main reason is that incremental compilation model is incompatible with symbol processing's.

First, the dirty sets are different. It's possible to use the union of the two dirty sets but that would introduce too much unnecessary recompilation and reprocessing in both side.

[Ting-Yuan Huang]

Secondly, incremental compilation in kotlin is done iterative. For example, it may compile A.kt and then find that B.kt need to be compiled as well, and then in the third iteration compile C.kt. In the planned model of symbol processing, we try not to deviate from annotation processing too much and want to provide all inputs at once.

[Ting-Yuan Huang]

Of course, if it's widely acceptable that all processors are "isolating" in KSP, then the second point in the above wouldn't be a problem. And then we can try to change the compiler a little bit and merge KSP back to the compilation task.

[Zac Sweers]

is merging it back in a goal or a nice-to-have-down-the-line-maybe?

[Ting-Yuan Huang]

On the performance of a separate task: There are two overheads that I know of. The first is the creation of the gradle task. This should be fine. The second is the invocation of the compiler. This is fine, too, because of the KotlinCompileDaemon.

[Zac Sweers]

Kapt would disagree with the second bit :X

[Ting-Yuan Huang]

It's more like the later to me.

[Ting-Yuan Huang]

May I know why?

[Zac Sweers]

KotlinCompile tasks are non-trivial overhead, prone to broken build caching, and more. I'd be curious to see updated benchmarks with the separate task, but I suspect it would be roughly the same speed as a kapt-using project but minus the stubs task

[Ting-Yuan Huang]

I don't know about the prone to broken build caching part. As for the overhead of KotlinCompile, I agree that it's non-trivial, but I think it is also pretty small when compared to stub generation and processing itself.

The other thing that ksp has an edge over kapt is incremental processing. Unlike kapt, which need to be conservative because it determines the dependencies statically, the dependencies in ksp are tracked dynamically. Therefore the dirty set in ksp should be much smaller than kapt and we hope that would translate to lower processing time.

[Zac Sweers]

this is the caching issue https://youtrack.jetbrains.com/issue/KT-34862

[Zac Sweers]

and I'm optimistic, but would want to see benchmarks before I could recommend wider adoption within our team as every solution in kotlin I've seen involving extra kotlinc invocations has quickly become a bottleneck (ABI jar gen, kapt, etc)

[Ting-Yuan Huang]

Thanks for letting me know the caching issue. It looks like a bug to me. We'll keep that in mind when implementing ksp.

[Ting-Yuan Huang]

The overhead caused by moving to a separate task is around 150ms on my machine. We'll prioritize reducing / eliminating it if we decided to move to a kotlinc incremental compilation compatible model.