LOL, it was hard finding docs about KSP. Maybe my Google-Fu isn't what it was. Is this the best so far? https://github.com/android/kotlin/tree/ksp/libraries/tools/kotlin-symbol-processing-api

Does Generator only support source files, or could it also generate resources?

Is there an equivalent to

Messager

? I’ve noticed that simple printlns don’t work for this case, so currently doing

error("here")

-driven-development 😁

Got a bug and repro case. As a demo I’ve been trying to write a ksp-version of AutoService, but when I read the

value

field from it (

Class<?>[]

), it just says it’s empty -

@AutoService(Processor::class)

. Will file with a link

hm, not sure if it's a bug or not, but I don't get a primary constructor if I don't explicitly define one. Imo it would be easier if it returned a no-arg constructor in that case. Don't think there's any value in differentiating between the two right?

class Foo --> primaryConstructor is null
class Bar() -> primaryConstructor is not null

Is the readme right to say the processor dependency should be

implementation

? I noticed that leaks it transitively to any downstream consumers of the original consuming project. Changing to

compileOnly

works fine for me in that case

Is the github repo up to date? Noticed the commit is from january, and wondering if it’s open to PRs

Hey, curious, what is the situation with Kotlin MPP support? I have noticed a tracking issue and afaik this processor is based on JVM only compiler extension, but do you plan to bring support to all platforms? Overall, very solid first impression, thanks for sharing this!

Just wanted to say I finally had some time to read through the docs, and wanted to send cudos to the devs. Cool work. Will this ever be able to perform AST/IR manipulation or will it only work on immutable mirrored types like the current processing API?

Not sure if I'm missing something, but can't figure out how to get the typealias name at a usage site. for example 'KSFunctionDeclaration.returnType' seems to only return the underlying type.

Will ksp be thread safe? Java annotation processing is not thread safe, as the

complete

call that javac invokes on type symbols to fill in information about the type does not synchronize on mutable state. In one of my complex annotation processors I have manually synchronized the Type completion so that I can parallelize processing with coroutines and it greatly sped up processing. It would be really nice if this was supported out of the box by KSP as it would allow processors to be faster

Hi, I try to implement KSP for my library instead of code generation. I cannot setup KSP. Processor doesn’t generate any code. https://github.com/moxy-community/Moxy/tree/feature/ksp Modules: moxy-compiler-ksp, sample-app-ksp. Can somebody help me? PR or explain my mistake

Is there a conventional way to read files on the compilation classpath? Context: my ksp-based implementation of AutoService is functionally complete, but one thing it doesn’t do yet that autoservice does do is merge existing services on the classpath into its generated file

Separately, is ksp supposed to be able to read types that are only added as compileOnly dependencies? I feel like the answer is yes but also think I was finding it wasn’t working. I can try to put together a repro case and file an issue if it is expected to work

Anyone comfortable with throwing out a hand-wavey timeline for KSP landing in the main line kotlin artifacts? even if just an opt in basis similar to how NewInference is I can make a better argument for jumping on it for a few concepts I am cooking up.

do you know of any projects that are already working on something along these lines?

Does JetPack Compose use KSP ?

Hello, we've just made another release at https://github.com/android/kotlin/releases/tag/1.4.0-rc-dev-experimental-20200731. Important changes are: * Introduced

KSPLogger

(only

logging()

with

gradle --debug

work for now) * KSP works on Windows now! * Rebased to 1.4.0-rc. Please remember to change

1.4-M1

to

1.4.0-rc

in gradle build scripts. Please give it a try!

I'm frustrated with KAPT because it doesn't do multi-pass, and I have annotations that use types generated by other annotations. Will KSP help me? does it do multi-pass? Or do I need to create more "child" gradle projects to ensure order?

Undocumented in public but I’m sure you could ask the right colleagues internally :) https://github.com/google/turbine

Looking at https://github.com/android/kotlin/pull/98, I’m not sure it quite solves the original issue as nicely as it could. Namely, one has to get the package name from the declaration and then remove it from the fully qualified name. It’s a little awkward not to have a nested naming API. I think it’d still be worth adding to the

KSName

API as well, then it would be easy for us to write something like

fun KSName.toClassName(): ClassName

in KotlinPoet or similar

Hi, is it possible to use custom processors as a dependency for JVM target in multiplatform projects?

Do you have plans to support unstructured code blocks? Like property initializers. For example given the class,

class Foo : Bar {
    val foo by bar()
}

It would be nice, from

foo

property, to retrieve the initializer

"by bar()"

as a code block / string that can be analyzed.

Was there ever an update on a KEEP? I am admittedly worried about investing into this without some formal confirmation from the jetbrains side that they plan to merge this considering they did not accept any of google’s previously contributed KEEPs

Hi everyone, Wanted to share an update on KSP and our development process. After discussing with the Kotlin compiler maintainers, we’ve decided to move KSP to its own repository on GitHub and decouple it from the compiler project. The Kotlin compiler teams at JetBrains and Google remain very committed to this project and making it a core part of the Kotlin toolchain. But, as the Kotlin compiler codebase grows in size and complexity, we’ve decided it makes more sense to decouple KSP to keep our development and releasing processes fast and efficient. That said, we will continue to rebase onto new versions of the Kotlin compiler and, in fact, you can check out our latest Kotlin 1.4.10-compatible release here. As always, we’re open to your feedback and suggestions — please don’t hesitate to reach out if you have any questions about this decision or anything else on KSP. Along with the repository change, we’ve also changed the package name as well. Here is an example of how to make your project use the new KSP release.

Published a couple more KSP libraries focused around Moshi too https://twitter.com/ZacSweers/status/1310145839105536001. Found one possible bad bug around generic type nullability, filed here along with a few other misc issues I found along the way

We have a very specific use case in Moshi where we want to invoke the defaults constructor of a class to respect default parameter values when we those keys are absent from json. This constructor is synthetic but present in bytecode, so currently we reflectively look up the constructor to invoke it. If we could generate bytecode, we could just make the bytecode invoke this constructor directly and make the generated adapter invoke this non-synthetic bridge method

having trouble figuring out how to replace a generic type param with a specific type. You can use

type.replace()

but you need a

KSTypeArgument

. and you can get a type argument from

resolver.getTypeArgument()

but you need a type reference. But I don't know how to get a type reference. You can do

resolver.getClassDeclarationByName("name").asType()

but that returns a

KSType

not a

KSTypeRefence

.

I noticed from a report someone else sent me with my plugin that KSP runs during all KotlinCompile tasks, which means it runs during kapt stub generation and kapt, before finally running in the regular compileKotlin task. Should it exclude itself from kapt tasks?

Is there already a good approach or DSL for annotating foreign types? For example in a multi-module project: module “model” contains all model types module “persistence” handles database serialization and thus needs database-specific annotations on types provided by “model” module “serialization” handles JSON serialization and thus needs JSON-specific annotations on types provided by “model” For proper abstraction, the annotations must not be put on the model types directly because that’s an implementation detail. And may vary depending on the dependent module.