We should materialize delegated declarations to process callables
in scopes correctly. Standalone mode works the same way as it
deserialize directly into FIR.
Another solution is to rework proto and stub serializer/deserializer to
restore FirFields like `$$delegate_0` correctly to work with
`FirDelegatedMemberScope`
^KT-62896 Fixed
^KT-64584 Fixed
getServiceIfCreated doesn't create a service instance if id wasn't
created before. There are no other service requests for
KotlinLabelProviderService, so it was not used for file types.
KTIJ-27755
Intercept decompiler calls to process files that belong to classpath
builtins from K2 IDE differently. Their content won't be filtered w.r.t.
JVM logic during decompilation.
Split stub versions for .kotlin_builtins with K1 and K2 IDE.
K2 currently uses a single shared symbol provider for builtins of all
platforms. KotlinBuiltInDecompiler filters out duplicated declarations
contained in JVM classfiles as required for K1. For K2 this logic
doesn't fit: non-JVM modules (common, in particular) rely on
.kotlin_builtins, because kotlin-stdlib-common doesn't contain
.kotlin_builtins or .knm files for some of the built-in declarations
(e.g., kotlin.Unit). IDE has to restore the missing declarations using
built-ins from classloader. Filtering declarations from there using K1
logic breaks resolution of these declarations inside common modules in
IDE. The change shouldn't affect JVM modules as are able to resolve
all builtin symbols from the standard library before falling back to
built-ins.
KT-61757
Track changes in K/N stubs directly instead of using the hack with
KlibMetaFileType.STUB_VERSION + KotlinStubVersions.BUILTIN_STUB_VERSION.
Changes in built-in stubs might or might not affect .knm stubs and
should be tracked independently.
The used offset constant for migration is the sum of the offsets from
KlibMetaFileType and KotlinStubVersions.BUILTIN_STUB_VERSION.
KTIJ-26761
KTIJ-26961
Annotation loaders for descriptors (AnnotationAndConstantLoaderImpl) and
stubs (AnnotationLoaderForStubBuilderImpl) share the loading logic until
mapping ProtoBuf.Annotations to output values. The shared logic has been
extracted to the base class.
KTIJ-26761
KTIJ-26961
Add annotation loading for property backing field, property delegate and
extension receiver to AnnotationLoaderForStubBuilderImpl. Use logic from
AnnotationAndConstantLoaderImpl.
AnnotationLoaderForStubBuilderImpl is used by KotlinMetadataDecompiler,
K2KlibMetadataDecompiler and KotlinJavaScriptMetaFileDecompiler. Stub
versions for built-ins (affects metadata and K/N decompilers) and JS
are bumped.
KTIJ-26761
KTIJ-26961
This is more consistent with the code of
the common compiler checkers.
It would be nice to refactor the contents
of this object further, but it's out
of scope of the current branch.
^KT-54596
Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
This name leads to inconsistency between FqName from stub and
FqName from ClassId.
The first one is `no_name_in_PSI_3d19d79d_1ba9_4cd0_b7f5_b46aa3cd5d40`
but the second one is `<no name provided>`.
We can't just replace SAFE_IDENTIFIER_FOR_NO_NAME to NO_NAME_PROVIDED
due to many places with unsafe logic inside type mapping.
^KTIJ-26848 Fixed
The test compares stub trees built from .knm files directly and from
the decompiled text. Test data for .class decompiler is reused,
JVM-specific cases are ignored
KT-61354
If a user has multiple kotlin-stdlib libraries in a project, all those stdlib libraries will contain builtins
which will result in resolution ambiguities.
To prevent such kind of ambiguities inside LLFirDependenciesSymbolProvider,
callables are grouped by facade class name.
Only matching callables from the first facade are used.
Facade is a Kotlin/JVM-term so right now it works only for JVM targets.
Builtins are also used in JVM, so the current solution is to have a Facade name also for builtins.
^KTIJ-26760
To avoid freezes and useless reporting calculations
#KTIJ-25465 Fixed
Merge-request: KT-MR-10996
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
Backend, which is used by the expression evaluator, relies on the class
name in 'FacadeClassSource'. To pass the correct JVM class name,
stubs for top-level functions and properties got the 'origin'.
if the compiled code is opened in the editor,
1. it's decompiled
2. stub is build over decompiled text
3. this stub replaces the stub built from classes.
This process leads to missed information in resulted FIR, e.g. half correct classId.
On the other side, this FIR is used only for this opened editor.
^KTIJ-24638
Notice on `DebugSymbolRenderer`:
stub based deserializer sets source directly,
but it's available in IDE mode only.
Thus, standalone and IDE tests have different results.
In order to avoid this, sources for compiled code are explicitly ignored
Notice on distinct callables:
for a file which belong to multiple libraries, decompiled code would be build per library.
In order to avoid ambiguity errors for members in that file,
we need to distinct provided elements by origins
failed test from IJ repo:
FirReferenceResolveWithCrossLibTestGenerated#testSetWithTypeParameters
Dmitrii Gridin