I just tested updating our project from using KSP ...

# ksp

[David Herman]

I just tested updating our project from using KSP 2.1.20-1.0.32 to 2.1.20-2.0.0, and I'm getting crashes in my KSP processors around resolving annotation arguments.
More details in the thread 🧵

[David Herman]

Basically, I have annotations which take a single value that has a default value.

For example:

annotation class Layout(@Suppress("unused") val fqn: String = "")

And I have KSP code that looks like this:

annotatedFun.getAnnotationsByName(LAYOUT_FQN).first().arguments.first()

We have code then that looks like this:

@Layout
fun SomeLayoutWhatever()

Previously, KSP would provide us with a single argument for that annotation, but now in 2.0.0, it seems like arguments is empty.

[David Herman]

It's trivial for me to fix up my code, but is this WAI from the KSP team or an oversight?

[Ting-Yuan Huang]

Sounds like a bug. A list that has a single empty String should be returned.

[Ting-Yuan Huang]

The comment in the API is a bit vague. arguments contains default arguments.

[David Herman]

Just did some a quick println check... When encountering @Layout in 1.0.32, I get a single argument back but value is null. In 2.0.0, I get zero arguments back.

So it's possible even 1.0.32 was bugged (unless, again, this is expected behavior for excluding default arguments in annotations)

[David Herman]

I assume expected behavior would be, as you said, a single argument with the value set to the default value.

[David Herman]

But I'm open to hearing that the current behavior is intentional. I don't think it would be this way, but maybe the expected action is I'm supposed to grab the original definition of the annotation and pull the default value out of there

[David Herman]

I assume you don't need a repro project from me? It should be pretty easy to set up a test case with the info in this thread, yeah?

[David Herman]

Looks like https://github.com/google/ksp/issues/2356 might be related?

[David Herman]

---
Note that that bug links to https://youtrack.jetbrains.com/issue/KT-59526/Store-annotation-default-values-in-metadata-on-JVM which looks like it's fixed and targeting 2.2.0-Beta2. Does that mean we can expect the KSP issue to be fixed soon too?

[Ting-Yuan Huang]

OK I see. Yep, if the annotation is defined in a non-jvm library, it is known broken. I need to check the fix to confirm when it will be ready for processors; The information will be available in the libraries compiled by Kotlin 2.2.0+, but that doesn't necessarily mean the compiler API that KSP uses is ready.

[David Herman]

Ah yes, that's an important detail and I'm sorry I didn't even think to mention it -- the layout is defined in a Kotlin/JS codebase.