https://kotlinlang.org logo
Title
j

Jiaxiang

11/06/2020, 11:22 PM
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.
👍 8
z

Zac Sweers

11/07/2020, 11:39 PM
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?
repro is https://github.com/ZacSweers/MoshiX, running
./gradlew :moshi-ksp:tests:test
no longer appears to run KSP and generate any subsequent code
1
e

evant

11/08/2020, 10:34 PM
running into the same thing, tried updating ksp and now no code is generated
z

Zac Sweers

11/09/2020, 2:54 AM
quick update, reverted the update on my repo, use this link https://github.com/ZacSweers/MoshiX/tree/324c8e03f2f61d3b4a0953687d5706968a35954b
j

Jiaxiang

11/09/2020, 6:45 PM
Thanks for reporting.. I’ll file a bug for tracking
t

Ting-Yuan Huang

11/09/2020, 8:52 PM
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.
z

Zac Sweers

11/10/2020, 1:51 AM
I'll give that a shot
t

Ting-Yuan Huang

11/10/2020, 1:55 AM
Thanks. I have a patch ready and will make another release tomorrow.
👍 2
j

Jacob Applin

11/12/2020, 1:39 PM
What is the benefit of moving KSP to a seperate task?
z

Zac Sweers

11/12/2020, 10:56 PM
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
t

Ting-Yuan Huang

11/12/2020, 11:03 PM
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.
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.
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.
z

Zac Sweers

11/12/2020, 11:15 PM
is merging it back in a goal or a nice-to-have-down-the-line-maybe?
t

Ting-Yuan Huang

11/12/2020, 11:15 PM
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.
z

Zac Sweers

11/12/2020, 11:15 PM
Kapt would disagree with the second bit :X
t

Ting-Yuan Huang

11/12/2020, 11:16 PM
It's more like the later to me.
May I know why?
z

Zac Sweers

11/12/2020, 11:18 PM
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
t

Ting-Yuan Huang

11/12/2020, 11:29 PM
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.
z

Zac Sweers

11/12/2020, 11:31 PM
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)
t

Ting-Yuan Huang

11/12/2020, 11:41 PM
Thanks for letting me know the caching issue. It looks like a bug to me. We'll keep that in mind when implementing ksp.
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.
👍 1