Can anyone kindly validate this concept? (It's be...
# compiler
d
Can anyone kindly validate this concept? (It's beyond the limits of the LLM's I've tried!) I want to write a developer productivity application that can analyse Kotlin source files for their types, members and call-tree. I imagine the most sustainable way of doing this is by levering Kotlin's own compiler; by writing a compiler plugin that can extract the information (types, members, call tree) during pre-compilation analyses. Given that I want this analysis to run as part of an Application, and not a Gradle build, can I configure the
kotlin-embeddable-compiler
with the plugin? I looked up 'Writing your first Kotlin Compiler plugin' but this focuses on Gradle, which is not really the angle I want to take (I think). Grateful for any thoughts 🙏
e
depends on what you want but in a lot of cases I would say that you can't get an accurate analysis without Gradle or other ways to feed the proper classpath and configuration into the compiler. otherwise you don't know if
foo(x)
refers to the local function
foo
or to
foo
from some import, or which scope an unqualified
bar
is from
https://github.com/detekt/detekt uses kotlin-compiler-embeddable for example, but also integrates with Gradle to extract the classpath, and is moving to a compiler plugin https://github.com/detekt/detekt/tree/main/detekt-compiler-plugin
d
Thanks @ephemient; I see your point about needing the correct class paths for a proper analysis, which are dependent on Gradle. Seems like invoking Gradle (probably via its Tooling API) with a plugin is the way to go after all - meaning the 'First Compiler Plugin' remains a relevant starting point.