Doing so speeds up psi2ir ~2 times, and thus improves total compiler
performance by about 6-8%.
Unless JVM IR is in the mode where linking via signatures is the only
way (-Xserialize-ir, -Xklib), signatures are actually not needed at all,
SymbolTable can use the frontend representation (descriptors for FE1.0,
and hopefully FIR elements for K2) as hash table keys. The only catch is
that since other backends still need to work with signatures, all the
common IR utilities, such as irTypePredicates.kt, need to work correctly
for IR elements both with signatures and without.
Also, introduce a fallback compiler flag -Xlink-via-signatures, in case
something goes wrong, to be able to troubleshoot and workaround any
issues.
#KT-48233
The function findDescriptorBySignature should return null if no such signature has been found
letting the caller to handle this correctly. Fixes https://youtrack.jetbrains.com/issue/KT-50976
Unfortunately, neither descriptors nor Lazy IR have enough information
to correctly deduce a enum's modality as psi2ir does, so to avoid the RTTI generator
generating different vtables in different setups (whether a klib is cached or not),
conservatively consider all enums non-final.
Before all files were going to `getOrCreateSymbolLightFacade`. If there
were both compiled and source files, it caused exceptions later
(see `SymbolLightClassFacadeCache.getOrCreateFirLightFacadeNoCache`).
When grouped by the `KtModule`, each file group should contain either
only sources or only compiled classes.
^KTIJ-20637 Fixed
The IDE expects the super type calls to resolve to the constructor
invoked and not the class. The frontend itself resolves to the
class, so an extra layer is needed to adjust that to the constructor.
These arguments are only used when 'kapt.workers.isolation=process' mode
is used. It allows users to apply workaround for running kapt on newer
JDK version without waiting for a new Kotlin release
^KT-48450 Fixed
Previously (few commits earlier), it contained two versions
of receiver (lhs) generated separately for each desugaring version
that looked a bit redundant.
Now, at FIR building stage we just don't create desugaring sub-trees,
instead they are being built during bodies transformation and that seems
to be much convenient there, since we don't need to reverse-engineer
get-set-operator version to check if containing calls are successful
(as we just built those calls and retain them)
Semantically, this changes may only change how data flow works
for such statements (see changed compatibilityResolveWithVarargAndOperatorCall.kt)
^KT-50861 Relates
It's necessary to allow a?.b += v be interpreted as a?.(b += v)
But currently FirAssignmentOperatorStatement is not FirQualifiedAccess
^KT-41034 In Progress
Static inline class replacements are possible only in inline classes.
Iterating over class declarations here took ~0.5% of backend time on
average projects, and up to 4% of total compilation time on degenerate
projects such as the one in KT-20055.
Before this commit we took just first intersection member for this check.
However it's quite bad, because we were dependent on supertype order.
Choosing the most specific member looks more consistent here.
#KT-50969 Fixed
Pavel Kunyavskiy