Note: Analysis API is currently under active development and does not provide any compatibility guaranties.
Analysis API is an API which allows analysing Kotlin code and retrieve compiler-related information. This includes: expression types, symbols, smartcast, and many others. Analysis API is an API which is used to implement Kotlin Plugin 2.0 which is under active development now.
Analysis API is Kotlin compiler implementation independent . That means that it do not expose any Kotlin compiler internals.
Analysis API itself is a just set of interfaces/abstract classes without specific implementation inside. But there are two implementations currently available.
Analysis API can work outside IntelliJ IDEA (e.g, it can be used for implementing Kotlin LSP server) but it still uses some basic classes form IntelliJ Core. This is needed mostly for working with PsiElements, lexical and syntax analysis.
The Analysis API defines services, extension points, service implementations, and so on in XML files. Such files are located in resources under /META-INF/analysis-api/ directory.
The implementor of the Analysis API has to register such definitions on its side.
/META-INF/analysis-api/analysis-api-fe10.xml file./META-INF/analysis-api/analysis-api-fir.xml file.KaSession is a view to the project modules and libraries from some fixed module, so called use-site module. From analysis KaSession we can see only modules and libraries which are transitive dependencies of the use-site module. KaSession contains set of functions to interact with Analysis API and it is the only way to interact with it.
KaSession has the following contracts:
KaSession receiver parameter should not be written to a variable or used as a function parameter. For decomposing analysis code which should happen in KaSession Scope consider passing KaSession as function receiver parameter.KaSession extension receiver: fun KaSession.doSmthWithSymbol(symbol: KaSymbol) {...}All interaction with the Analysis API should be performed only in KaSession Scope. To enter such scope analyse function should be used:
fun <R> analyse(contextElement: KtElement, action: KaSession.() -> R): R
Where action lambda represents the KaSession Scope.
Every Lifecycle Owner has its lifecycle which is defined by corresponding KaLifetimeToken. There is a special function analyseWithCustomToken which allows specifying needed behaviour. There are also analyse function which is made for the IDE which analyses with KaReadActionConfinementLifetimeToken
KaReadActionConfinementLifetimeToken has the following contracts:
analyseInModalWindow function instead (but it may be rather slow and also shows a modal window, so use it with caution)analyse(context) { ... } lambdaKaSymbolis an Lifecycle Owner that describes Kotlin or Java (as Kotlin sees it) declaration. KaSymbolrepresents:
Consider you want to take a symbol you got in one KaSession Scope and use in another. It cannot be done directly as KaSymbol can not be leaked outside KaSession Scope. But there is such thing as KaSymbolPointer. For every KaSymbolcorresponding KaSymbolPointer can be created in one analysis session and symbol can be restored by using it in another. If between creating a symbol and restoring it, corresponding declaration changed then the symbol will not be restored and KaSymbolPointer.restore call will return the null value.
KaType is an Lifecycle Owner that represents a Kotlin type in compiler-independent way.
The Lifecycle Owner which can answer the following queries:
For now the following scopes available: