null value in annotation arguments if annotation originates from Java and argument is Kotlin's const val

[Jeffset]

Assume we have a Kotlin source, named Constants.kt, as follows:

const val FOO = "foo"

And a Java source:

class Bar {
    @Named(ConstantsKt.FOO) void set(/* */) { /* */ }
}

When @Named annotation (KSAnnotationJavaImpl) is resolved, it yields ["value:null"] from its arguments property, with no way to retrieve the "foo" value.

Named = javax.inject.Named for completeness.

So, basically, Kotlin constants are not properly resolved in Java annotation arguments.

[Jeffset]

I've edited the description, as it indeed only fails to resolve, if const val is top-level.

[Jeffset]

The issue is that JavaPsiFacade.findClass() yields null when resolving synthetic file facade classes (e. g. ConstantsKt), thus any references from Java code to Kotlin top-level properties/functions are virtually inaccessible for KSP.

I'm not sure how to correctly resolve the issue, for now it seems that PsiReference.resolve() (and PsiConstantEvaluationHelper.computeConstantExpression() in turn) for Java Psi Impls have no notion about Kotlin's facade classes; yet Kotlin plugin for intelliJ, which is backed by Kotlin compiler code, correctly resolves these (?) references from Java, obviously.
So should we develop a workaround on the KSP level, or apply some other Kotlin-aware approach for computing constant expressions, or is this an issue with core compiler code?

[Jeffset]

Also this leaves us with the fundamental problem - how to model synthetic file facades in KSP, if they are used as classes directly, like in @SomeAnnotation(clazz = ConstantsKt.class). For now we are getting ErrorType there.

[neetopia]

I am thinking about adding a synthetic implementation of KSFile for such file classes, still trying to recall why I did not have such classes in place.

[neetopia]

One problem I can think of is the name mangling, we might end up replicating the name mangling logic for file classes.

[Jeffset]

Thanks for the fix!