curious on thoughts of representing function types. Right now it seems like the are converted to their class references, so

(Int) -> String

has the type

kotlin.Function1<Int, String>

and

suspend (Int) -> String

has the type

kotlin.coroutines.SuspendFunction1<Int, String>

would it make sense to represent these more specially as function types? Or maybe have some helpers to detect if a type is a function type, what it's args/return type is, if it's suspend etc?

Any special reason to have

SymbolProcessor#init

like annotation processor interfaces do? Having

init

and

process

in the same interface forces the declaration of `var`s to reference arguments from

init

for later usage in

process

. IMO a better approach would be a factory/provider interface:

// ServiceLoader would load this instead
interface SymbolProcessorFactory {
    // same args passed to init
    fun create(codeGenerator: CodeGenerator, ...): SymbolProcessor
}

interface SymbolProcessor {
    fun process(...)
    fun finish()
}

Although it would be a little more work to implement, there are some pretty concise ways of doing it:

class Processor(private val codeGenerator: CodeGenerator) : SymbolProcessor {
    override fun process(...) { ... }

    object Factory : SymbolProcessorFactory {
        override fun create(codeGenerator: CodeGenerator, ...) = Processor(codeGenerator) 
    }
}

This would allow full immutability.

At the live event it seemed like they insinuated that KSP is ready for multiplatform use. Is it?

So I get that KSP is faster than annotation processors, but how much overhead do they add? They are incremental right?

I know it’s a bit late, but I’m curious what you’d think of an alternative approach for that new API Right now it’s this

fun asMemberOf(
    property: KSPropertyDeclaration,
    containing: KSType
): KSType

Which feels a little java-y. What about this?

fun KSPropertyDeclaration.asMemberOf(
    containing: KSType,
    resolver: Resolver
): KSType

Hello, I wonder if KSP could help me show some function call as a compile time error, let me explain:

enum class Value {
    Default, Value1, Value2
}

class SomeClass(val values: List<Value>) {

    fun hasValue1() = values.contains(Value.Value1)
    fun hasValue2() = values.contains(Value.Value2)
}

fun main() {
    val someClass = SomeClass(listOf(Value.Default, Value.Value1))
    someClass.hasValue2() // how to make this call compile time error?
}

As

someClass

does not contain

Value.Value2

in its

values

property, I would like to make a call to

hasValue2

a compile time error. Is it possible to do so?

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.

Hi, here is a release which includes a fix to a dependency bug introduced in the release of 20201106. This release also includes an ABI change from another commit so processors using

getSymbolsWithAnnotation

will need to be rebuilt. https://github.com/google/ksp/releases/tag/1.4.10-dev-experimental-20201110

I updated my bytecode generation branch, but it doesn't appear to be working. The classes themselves do get generated, but they don't link at compile-time

Is there anything I could do to help with the generated bytecode stuff? Alternatively @gavra might have some advice too as he looked into it for kapt in the past

something I noticed in raw compiler code - functions and properties both implement a

KtCallableDeclaration

type to help share with code that can call a function or property. Thoughts on matching this with a

KSCallableDeclaration

?

Just to verify my thinking - ksp is "compatible" with incremental compilation now insofar as the separate KSP task is non-incremental but the regular kotlinCompile task that follows it doesn't know anything about KSP and thus runs incrementally as normal?

And one last one - with ksp being a separate task now, is there any thought to possible allowing ksp mixing into an existing/standard project that otherwise uses standard kotlin? I'd like to look at using ksp in small isolated parts of our project, but last time I tried it seemed you either have to use KSP's fork for everything in the repo. Or if that's the goal anyway, any sense of allowing for that sooner than stable to help facilitate wider adoption/testing?

I'm actually curious how ksp's separate task runs without the same overhead as the normal

compileKotlin

task. I imagine it maybe runs the frontend only (i.e. not the backend?), but I thought the frontend was also where the bulk of the slowdown was and being replaced with

fir

. On paper it seems like this is effectively running compilation twice like kapt does in its task, which presumable would work via similar mechanism

Hi KSP friends — I know it’s generally faux-pax to ask about product roadmaps (I have Chet Haase in my head, _“We don’t talk about the future_”), but I wanted to ask about the plan for KSP to graduate to alpha (or something less experimental) in 2021 (or beyond). I’m sure there’s blocking upstream compiler work that needs to land — are there tickets on Jetbrains’ side that I can follow to get a better sense of when KSP might have a chance of moving up the stability ladder?

Considering how far away KSP is from stable, does

@KspExperimental

make sense? I've kind of always only thought of experimental annotations being necessary for stable APIs, feels like unnecessary friction in something that is still being actively developed anyway

Hi, here is another release of KSP: https://github.com/google/ksp/releases/tag/1.4.20-dev-experimental-20201222 This release introduced an experimental incremental processing support, which can be enabled via the Gradle property 

ksp.incremental=true

. Logs can be enabled by 

ksp.incremental.log=true

. They are disabled by default so no worries :-) Incremental processing in KSP relies on processor's knowledge of how inputs are associated with outputs. Therefore, a new parameter is introduced to 

CodeGenerator.createNewFile

. There is also 

CodeGenerator.associate

 to associate inputs and outputs, in case the relation isn't clear when creating the outputs. This is an API change that breaks existing code. Please see the API for details. Please give it a try and share your thoughts! We need your help to improve the API.

is there any scenario where

dependOnNewChanges

would be false?

one other question around incremental support -> should we de-dupe originating files in the processor or will KSP handle that?

one more other question: how should classes defined via metadata (but not class hierarchy) work? Example case: I have a processor that generates an adapter for a sealed class and references all of its sealed subtypes. I've treated it as basically "isolating" up until now because we could get all the information from the original sealed class

so Room is getting close to adding KSP support such that i was able run a compile time comparison between kapt and ksp (for room kotlin integration testapp). tl;dr; using KSP makes it ~50% faster 🙂 To my surprise, even the ksp task is faster than kapt's processing step (without stubs). This is not very scientific so i might be doing something wrong but these are very encouraging numbers

script used:
<https://android-review.googlesource.com/c/platform/frameworks/support/+/1531924/11/room/ksp-kapt-comparison.sh>
10 runs (clean compile test app):
 
total time spent in each group's tasks:
kapt : 34584 ms
ksp : 18671 ms
 
individual task totals:
kaptGenerateStubsDebugAndroidTestKotlin : 11751 ms
kspDebugAndroidTestKotlin : 17400 ms
kaptDebugAndroidTestKotlin : 21407 ms
kaptAndroidTestDebug : 0 ms
kapt : 0 ms
kaptAndroidTest : 41 ms
kspDebugKotlin : 1225 ms
kaptGenerateStubsDebugKotlin : 799 ms
kaptDebugKotlin : 586 ms
ksp : 46 ms
kaptDebug : 0 ms

Hi, here is a new KSP release: https://github.com/google/ksp/releases/tag/1.4.20-dev-experimental-20210107 Hightlights Breaking Change Starting from this release, we added gradle plugin marker and changed plugin id from 

symbol-processing

 to 

com.google.devtools.ksp

. Now you may remove the 

resolutionStrategy

 for KSP in 

setting.gradle.kts

 since it is no longer needed. See playground in attachment for full detail. We also planned to enable incremental processing in next release. Here is a doc describing how to use it and also a few examples. Please give it a try! Issues fixed: released POM files do not list dependencies #187 [Gradle Plugin] Publish plugin marker #203 Incremental logging does not create a file first #210 PRs merged: multi-module tests: make sure javaOut exists before passing to compiler #235 Setup depenedencies in compiler plugin’s POM #233 Report INNER modifier for class descriptors #232 Rebuild if processing options changed #229 Don’t calculate incremental info when incremental processing is disabled #227 Make kspTask depends on processors #222 Refine incremental logs #221 document for incremental processing #220 Rename dependOnNewChanges to aggregating #219 Use property descriptor impl for java properties #217 Add generated resource dir to proper sources and outputs #215 Gradle plugin publishing setup #206

I get this warning with the latest release 🤔 . Should I file?

> Task :moshi-ksp:moshi-ksp:compileTestKotlin
w: Some JAR files in the classpath have the Kotlin Runtime library bundled into them. This may cause difficult to debug problems if there's a different version of the Kotlin Runtime library in the classpath. Consider removing these libraries from the classpath
w: /Users/zsweers/.gradle/caches/modules-2/files-2.1/com.google.devtools.ksp/symbol-processing/1.4.20-dev-experimental-20210107/95a5ba4b6dd106b77cbbdc06f1491984b3c6b5/symbol-processing-1.4.20-dev-experimental-20210107.jar: Library has Kotlin runtime bundled into it

I'm also unable to compile with it, it seems like it tries to force the

JavaCompile

task to run even if there are no java source files

* What went wrong:
Execution failed for task ':moshi-ksp:moshi-ksp:compileJava'.
> no source files

I tried to set this option for kotlin compile task - https://youtrack.jetbrains.com/issue/KT-43704#focus=Comments-27-4625141.0-0 , but still not working.

KSP doesn't support multiplatform yet, right?

is it possible to use KSP side by side with KAPT for now? e.g: 1. Glide will use KSP 2. others still use KAPT (at least for library that still not supported using KSP) if there’s a similar question for this, maybe anyone can refers me which thread (I’m unable to find the right keyword search for this)

I'm trying to write tests that use generated code, and while my IDE thinks everything is perfectly fine the build fails because of missing symbols when running

test

after making changes and having built before (it works after clearing the

.gradle

cache). I have of course added the generated sources to the source set like so

kotlin {
    sourceSets {
        main {
            kotlin.srcDir("build/generated/ksp/main/kotlin")
        }
        test {
            kotlin.srcDir("build/generated/ksp/test/kotlin")
        }
    }
}

is there anything else that can be done in order to allow access to generated sources in tests?

should we hold off on

1.4.30-1.0.0-alpha02

?