The processor is supposed to generate types based on properties specified elsewhere. The actual processor is more complex, but this example is enough to show the issue it is running into: Imagine something like this:

@MyAnnotation
object MyProperties {
    @MyPropertyAnnotation
    val abc: Property<Int> = // ...
}

And I want to generate:

data class MyType(
    val abc: Int = MyProperties.abc.default
)

The above works very well, but now I'm doing this:

@MyAnnotation
object MyProperties {
    @MyPropertyAnnotation
    val abc: Property<Int> = // ...

    @MyPropertyAnnotation
    val def: Property<List<MyType>> = // ...
}

The expected result would be something like this:

data class MyType(
    val abc: Int = MyProperties.abc.default,
    val def: List<MyType> = MyProperties.def.default
)

However, I cannot resolve the type of the

MyProperties.def

property because it has not been generated yet, and I also cannot push it to the next round, because then

MyType

would still not be generated. I already know there will be a

MyType

before having to resolve the type of the property, so my hope was to register a

PackageFragmentProviderExtension

with the compiler that could already provide the types that are about to be generated, so that KSP would be able to resolve them. But this doesn't seem to work, even when I disable blocking other compiler plugins. Is there any other way to solve this issue? Thank you very much!

I got the package fragement provider to work now. Turns out my

PackageFragmentProvider

was returning a

ClassifierDescriptor

with a type argument that had the

containingDeclaration

set to the package fragment instead of the classifier... which caused it to not match the type I couldn't resolve. With that fixed, I can now successfully compile the module, but this of course still relies on the (deprecated) feature of allowing other compiler plugins, so it would not work anymore in the next version. Perhaps there should be a possibility to explicitly mark a compiler plugin as "written to work with KSP", so it wouldn't be blocked? Since there is multi-round processing which handles most of these cases, I think this specific case is probably be too much of an edge case to add support for it within KSP.