Previously it handled `FirResolvedNamedReference` and `FirThisReceiverReference`,
but the second one effectively was never passed to this function. It
happened because `FirThisReceiverReference` is present only in `FirThisReceiverExpression`,
which is processed separately in `Fir2IrVisitor.visitThisReceiverExpression`,
and its implementation don't call `toSymbolForCall`
This change uncovered the following problem in pipeline: we have a contract,
that all bodies will be generated after all fake overrides will be preprocessed.
But DataClassMembersGenerator generates bodies before f/o creation,
which leads to the problem, if data class has forward reference to some
class which was not processed before (because in this case generator
of `hashCode` function will try to reference f/o, which is not created yet,
which leads to `SymbolAlreadyBound` problem)
```
data class Some(val a: A) {
generated fun hashCode(): Int {
return a.hashCode() // (1) is not generated yet
}
}
class A {
fake-override fun hashCode(): Int // (1)
}
```
This problem will be fixed in the next commit
(related test is compiler/testData/codegen/box/ir/kt52677.kt)
^KT-60924
single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
If used toolchain JavaVersion is not yet supported by the current Kotlin
compiler, we are now fallback to the highest supported JVM target
version instead of failing the build.
^KT-58987 Fixed
Currently, when generating a TypeInfo with a vtable attached, the K/N
compiler generates two globals to the resulting LLVM module:
- "ktypeglobal:$fqName#internal" -- an internal global of the aggregate
type (TypeInfo+vtable)
- "kclass:$fqName" -- an internal or hidden alias pointing to the
TypeInfo part of that global
The reason for emitting two globals is to have everything strict-typed,
since other LLVM modules might import the kclass as a TypeInfo.
Importing an aggregate TypeInfo+vtable global as a TypeInfo global works
too, of course. It is just a little bit less clean.
The new Xcode 15 linker now emits symbols for the ktypeglobal to the
symbol table, including an STSYM. This happens for classes compiled to
cache, when the kclass is hidden, not internal.
The problem is: for some reason, such an STSYM for
"ktypeglobal:kotlin.String#internal" makes lldb find a wrong address
(0xffffffffffffffff) for "kclass:kotlin.String", despite those being
two different symbol names. This seems to be related to them having
the same address though.
The K/N lldb script, konan_lldb.py, uses "kclass:kotlin.String" to
determine if an object is a string, in order to display it properly.
Therefore, using the new Xcode 15 linker when compiling with caches
makes the debugger unable to display string variables properly. As a
side effect, this also breaks displaying array-typed variables (because
the script first checks if an object is a string).
This commit fixes this by removing ktypeglobals completely, making the
compiler emit only a kclass as an aggregate global directly.
Now, there are other ways to fix the problem. For example, making the
ktypeglobal private instead of internal, or making konan_lldb.py use a
runtime function instead of querying "kclass:kotlin.String" directly.
But it seems that LLVM aliases are not common on darwin platforms. For
example, Clang doesn't support `__attribute__((alias(...)))` on these
platforms.
So it is safer to just stop using aliases here.
^KT-61417
Dmitriy Novozhilov