A modern programming language that makes developers happier.

kotlinlang

Is it not possible to find annotated references from dependencies with FIR without knowing the exact `FqName`, right? So the only workaround about this is that the Gradle Plugin uses something like Classgraph to find those references and pass them to the compiler when syncing/building?

The `CompilerConfiguration` you get in the `CompilerPluginRegistrar` also gives you the list of classpath roots, so you can also run classgraph directly in the compiler plugin without needing to pass a list of external names to the plugin from gradle. Of course the downside with this is that gradle doesn't handle the caching, so you have to figure that out yourself.

This builds the list of files for all classpath elements:
```val elements = buildList {
    addAll(configuration.jvmClasspathRoots.map { it })
    addAll(configuration.jvmModularRoots.map { it })

    // The output directory is also in the classpath roots, might make sense to remove
    // it or at least handle it in a special way:
    configuration.outputDirectory?.let { outputDir -&gt;
        removeIf { it.startsWith(outputDir) }
    }
}

val result = ClassGraph()
    .overrideClasspath(elements)
    .enableClassInfo()
    .enableAnnotationInfo()
    .scan()```
For me this works when running the compiler through Gradle, but there is also stuff like `VirtualJvmClasspathRoot`, and intellij might use that instead for example, I haven't tried that yet.

Cannot this slowdown the IDE autocomplete?

I guess it depends on what you do, I actually need the ClassGraph results at the FIR stage to show errors and such, so I made everything lazy and cached. If I were to pass the external scan result through Gradle I wouldn't have it in the IDE at all. But it's definitely a trade off, if the external results are only important for IR, then it would still be possible to delay this until the actual IR phase by making it lazy I guess.

I don't actually run the scan in the `CompilerPluginRegistrar`, I pass the list of elements to a `FirExtensionSessionComponent` which then handles all the caching.

The "real" solution will hopefully be this (or one of the similar issues): <https://youtrack.jetbrains.com/issue/KT-54850/>

Is this working on tests with the official framework?