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
Lists have defined contracts for equals and hashCode and thus might be used as map keys for the sake of caching. Gradle's file collections do not follow those contracts, leading to cache misses and creating too many classloaders.
#KT-61426 Fixed
In partial module compilation, especially inside the IDE, only a few
files from the project are passed to fir2ir. FIR in these files might
contain references to declarations from other files.
As the FE doesn't usually care about called property initializers,
called properties might be resolved to 'CONTRACTS' or even 'STATUS'.
The backend, however, might need to inline constant expressions from
properties.
'CodeFragmentCapturedValueAnalyzer' assumes the analyzed code fragment
is then passed to the backend. For property calls, there are several
code generation strategies (field, accessor, delegate). In order to
be able to choose one, the whole property, including its possibly
'const' initializer, must be resolved.
The commit fixes a plenty of 'FirIdeNormalAnalysisSourceModuleCompilerF\
acilityTestGenerated.CodeFragments.Capturing' tests that broke after
the 'FirExpression.type' refactoring.
We should protect return types from value parameters/property accessors
and backing fields from repeatable modifications.
Such declarations can be modified during type resolution by
`transformTypeToArrayType` or property getter type propagation,
so we should be able to restore the original reference in the case of
exceptions (PCE for instance)
^KT-61422
It is true that for vararg parameter `arrayElementType` always have to
be not null, but it required resolution to TYPES phase. But in case of
the error type, the type reference is treated as resolved, so we are not
obligatory to resolve such reference to TYPES, because we already have
the resolved type.
So we can make the rule of KtFirValueParameterSymbol#returnType less
strict, and varargElementType will effectively do the same as
lazy resolve + arrayElementType
^KT-61422 Fixed
This change expanded KAPT to support a new param
'fileAccessHistoryReportFile', which reports all the classes used during
annotation processing into a file, in the form of a list of URIs.
This is useful for build speed improvements described in https://engineering.fb.com/2017/11/09/android/rethinking-android-app-compilation-with-buck/.
Essentially, using the list of used classes, we can compile only
the dependencies that are really affected by the developer's
code changes and improve Kotlin build speed.
^KT-52853
aleksandrina-streltsova