* thread that by default joins in the destructor (like C++20 jthread)
* can be given a name
Merge-request: KT-MR-5619
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
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
Igor Yakovlev