Previously, it was necessary because otherwise reporting diagnostics
from a checker of FirFile level didn't work
Now, it has been fixed in the previous commit
Previously, it was working for all the checkers but the file-level
DeclarationChecker's because when execution comes to
DeclarationCheck::check for a file, `containingDeclarations` is empty
(it doesn't contain the file itself yet), thus some things that rely on
CheckerContext::containingFile don't work properly.
For example, SimpleDiagnosticsCollectorWithSuppress.report that
effectively doesn't collect diagnostics when the containingFile is null.
This dependency has non-relocated 'com.intellij' types which could
lead to build errors if build classpath will have it earlier in the list
then kotlin-compiler-embeddable.
^KT-56414 Fixed
1. Introduce CExportFiles class
This class aggregates all files that are created specifically for
C export. Adding more such classes for other output kinds should
help getting rid of OutputFiles class.
2. Remove NativeGenerationState.tempFiles
Making NativeGenerationState (and compiler phases in general)
unaware of files and their lifetime is necessary for making phases
simpler and easier to compose.
We want to extract tempFiles from NativeGenerationState.
To do so, we need to move creation of NativeGenerationState from
`splitIntoFragments` function and untie CacheLlvmModuleSpecification
from NativeGenerationState
Continue extracting all temporary files to the driver, so we have
a better control over them. For example, this allows creating of a new
driver where pipeline split between multiple compiler invocations.
Example:
```stacktrace
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 32 out of bounds for length 17
at com.intellij.util.containers.RefHashMap$MyMap.rehash(RefHashMap.java:85)
at it.unimi.dsi.fastutil.objects.Object2ObjectOpenHashMap.insert(Object2ObjectOpenHashMap.java:251)
at it.unimi.dsi.fastutil.objects.Object2ObjectOpenHashMap.put(Object2ObjectOpenHashMap.java:259)
at com.intellij.util.containers.RefHashMap.putKey(RefHashMap.java:160)
at com.intellij.util.containers.RefKeyRefValueHashMap.put(RefKeyRefValueHashMap.java:55)
at org.jetbrains.kotlin.analysis.api.fir.KtSymbolByFirBuilder$FunctionLikeSymbolBuilder.buildFunctionSymbol(KtSymbolByFirBuilder.kt:727)
at org.jetbrains.kotlin.analysis.api.fir.scopes.FirScopeUtilsKt$getCallableSymbols$1$1$1$1.invoke(firScopeUtils.kt:25)
at org.jetbrains.kotlin.analysis.api.fir.scopes.FirScopeUtilsKt$getCallableSymbols$1$1$1$1.invoke(firScopeUtils.kt:24)
at org.jetbrains.kotlin.fir.scopes.impl.FirClassDeclaredMemberScopeImpl.processFunctionsByName(FirClassDeclaredMemberScope.kt:103)
```
^KTIJ-22749
For the following example, when we run the reference shortener, it
drops `a.b.c` qualifier, because it matches "FOURTH".
```
package a.b.c
fun <T, E, D> foo(a: T, b: E, c: D) = a.hashCode() + b.hashCode() + c.hashCode() // FIRST
fun <E> E.foo() = hashCode() // SECOND
object Receiver {
fun <T, E, D> foo(a: T, b: E, c: D) = a.hashCode() + b.hashCode() + c.hashCode() // THIRD
fun foo(a: Int, b: Boolean, c: String) = a.hashCode() + b.hashCode() + c.hashCode() // FOURTH
fun test(): Int {
fun foo(a: Int, b: Boolean, c: Int) = a + b.hashCode() + c // FIFTH
return <expr>a.b.c.foo(1, false, "bar")</expr>
}
}
```
As shown in the above example, when SHORTEN_IF_ALEADY_IMPORTED option is
given from a user, the reference shortener has to check whether it can
drop the qualifier without changing the referenced symbol and if it is
possible to do that without adding a new import directive, it deletes
the qualifier.
It needs two steps:
1. Collect all candidate symbols matching the signature e.g., function
arguments / type arguments
2. Determine whether the referenced symbol has the highest reference
priority when we drops the qualifier depending on scopes
This commit uses `AllCandidatesResolver(shorteningContext.analysisSession.useSiteSession).
getAllCandidates( .. fake FIR call/property-access ..)` for step1.
For step2, we use a heuristic based on scopes of candidates. If a
candidate symbol is under the same scope with the target expression, it
has a `FirLocalScope` which has the high priority. So when we have a
candidate under a `FirLocalScope` and the actual referenced symbol is
different from the candidate, we must avoid dropping its qualifier
because the shortening will change its semantics i.e., reference.
The order of scopes depending on their scope types is:
1. FirLocalScope
2. FirClassUseSiteMemberScope / FirNestedClassifierScope
3. FirExplicitSimpleImportingScope
4. FirPackageMemberScope
5. others
Note that for "others" the above rule can be wrong. Please update it if
you find other scopes that have a priority higher than the specified
scopes.
One of non-trivial parts is the priority among multiple
FirClassUseSiteMemberScope and FirNestedClassifierScope. They are
basically scopes for class declarations. We decide their priorities
based on the distance of class declaration from the target expression.
Note that we take a strict approach to reject all false positive. For
example, when we are not sure, we don't shorten it to avoid changing its
semantics.
TODO: One corner case is handling receivers. We have to update
```
private fun shortenIfAlreadyImported(
firQualifiedAccess: FirQualifiedAccess,
calledSymbol: FirCallableSymbol<*>,
expressionInScope: KtExpression,
): Boolean
```
The current implementation cannot handle the following example:
```
package foo
class Foo {
fun test() {
// It references FIRST. Removing `foo` lets it reference SECOND.
<caret>foo.myRun {
42
}
}
}
inline fun <R> myRun(block: () -> R): R = block() // FIRST
inline fun <T, R> T.myRun(block: T.() -> R): R = block() // SECOND
```
Tests related to TODO:
- analysis/analysis-api/testData/components/referenceShortener/referenceShortener/receiver2.kt
- analysis/analysis-api/testData/components/referenceShortener/referenceShortener/receiver3.kt
FirReferenceResolveHelper internally checks whether the referenced class
id matches the qualifed access or not. If they do not match, it reports
an error. When the companion object has the same name as the class,
resolving a qualified expression access to a member of the companion
object causes an error because of the mismatch e.g.,
```
package my.sample
class Test {
fun a() {
my.sample.<caret>Test.say()
}
companion object Test {
fun say() {}
}
}
```
This commit fixes the issue.
TODO: When the companion object has a name difference from class, it
does not report an error but the resolution result is wrong in FIR. See
KT-56167.
---
Commentary from rebaser: the issue mentioned in this code is
fixed in 71a368e06e, so the actual
fix is omitted, and only test data is preserved
They are disabling error for using JS/Legacy backend via System property
by passing it to the Kotlin Daemon. But daemon may already be started
and not contain such property.
Workaround for now is to use 'in-process' compilation for such cases.
Sebastian Sellmair