A type alias may still be inherited from. For example:
```
sealed class MyClass
typealias T = MyClass
class Inheritor : T() // `Inheritor` is a direct inheritor of `MyClass`.
```
The index is a simplified version of the IDE's
`KotlinTypeAliasByExpansionShortNameIndex`, but it should be sufficient
for virtually all cases.
^KT-66013
- The fix uses relevant logic from `getNonLocalContainingDeclaration`.
- The annotation entry case is covered by `KtCallElement` because
`KtAnnotationEntry` is a subtype of it.
- KT-66038 is fixed by this because the static declaration provider only
indexes non-local classes.
^KT-66038 fixed
In K1, code fragment analysis was completely invalidated on any PSI
change. Because imports are not a part of the PSI tree of
'KtCodeFragment's, a colon tremble happened on 'addImportsFromString()'.
In K2, changes inside code fragments are always considered in-body
modifications. So, even with the colon trembling, the 'FirFile',
together with its 'FirImport's was not recreated.
^KT-65600 Fixed
Here is the reasoning behind that change:
Historically, all the declarations generated by compiler plugins
were marked with `SYNTHESIZED` member kind in Kotlin Metadata
by K1 compiler.
In K1 IDE, descriptors were deserialized directly from the Kotlin
Metadata, and they saw all the generated declarations from it.
In the stubs, however, such declarations were not materialized at all.
It caused no troubles, since K1 IDE relied on descriptors to get the
essential resolution information in completion and other subsystems.
So, the resolution of members from jars processed
by compiler plugins (e.g. `kotlinx-serialization-json`) was mostly fine.
In K2 IDE, however, we use stubs to "deserialize" FIR declarations from
them, to later create `KtSymbol`s upon that FIR.
If we see a library file which was processed by compiler plugins, we
build stubs for it based on the Kotlin Metadata, and then use stubs to
create FIR.
But if stubs do not contain information about the generated
declarations,
then the resulting FIR will also not contain such declarations.
In the end, the K2 IDE would also be blind to such declarations, since
there is no other way to retrieve them from the library jar.
By meterializing all the synthethic declarations in stubs (with some
minor exceptions for data classes), we would avoid such problems,
and the resolve of such declarations from compiler jars in
K2 IDE would become possible.
Important note: currently, the Kotlin Metadata format between K1 and K2
frontends is not 100% the same; most notably, in K2, the generated
declarations are marked as regular declarations,
not as `SYNTHESIZED` ones.
Hence, if you compile a jar with the current version of K2 frontend,
then all the generated declarations would have a regular `DECLARATION`
origin, and there would be no such issues as described above.
There are two notes here:
1. K2 IDE still has to support the jars compiled by the K1 compiler,
so it still makes sense to alter the stubs and make the generated
declarations visible.
2. The issue about the different stub formats has been reported
(see KT-64924), and might be resolved in the future.
So it is possible that K2 frontend's metadata will also start
marking the generated declarations as `SYNTHESIZED`.
^KT-64808 Fixed
Fix the order of pointers and place logical operators first
#KTIJ-28165 Fixed
Merge-request: KT-MR-14447
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
Review: https://jetbrains.team/p/kt/reviews/14224/timeline
Timeline:
**(1)** Kotlin 1.1.60 https://github.com/JetBrains/kotlin/commit/59efedf610a25b004edf3d19897ce4dfca28ddb2 `header` keyword is introduced (committed on Dec 13, 2016)
**(2)** Kotlin `header`/`impl` has been deprecated (warning) at least since 1.1.60 https://github.com/JetBrains/kotlin/commit/5d251062677e09d607f295189b7978d5833e448f (committed on Sep 15, 2017)
**(3)** 1.1.60 release https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-compiler/1.1.60/ Nov 13, 2017
It sounds stupid but it looks like `header` was introduced and
deprecated right in the same release. Though it may be possible that we
had a release between **(1)** and **(2)** that I couldn't find
Anyway the keywords have been deprecated since basically forever
The fix is not perfect
"The perfect fix" would be:
1. Introduce a separate `DEPRECATED_MODIFIER_ERROR` diagnostic
2. Introduce LanguageVersionSettings for the `DEPRECATED_MODIFIER_ERROR`
diagnostic
But "the perfect fix" requires:
1. Adopting `ReplaceModifierFix` in the IDE to make it work with the new
diagnostic. `ReplaceModifierFix` is only implemented in K1 IDE. So
there are two ways:
1. Create a KTIJ ticket to port the diagnostic to K2 IDE (it needs to
be ported anyway), and **mention** in the ticket that
`DEPRECATED_MODIFIER_ERROR` also needs to be supported in K2 IDE.
It's the ticket that nobody will probably find and fix
2. Go and port `ReplaceModifierFix` to K2 IDE myself. It's fairly
simple task, but I've not worked in intellij for quite a while,
and it will take me too much time to index and compile
Considering that DEPRECATED_MODIFIER diagnostic is used only to report
`header`/`impl`, and there are literally 0 known cases when people use
it. It's just easier to convert the diagnostic to error in K2
Related tests:
- compiler/testData/diagnostics/tests/multiplatform/deprecated/header.kt
^KT-59839 Fixed
After `4b8b7aaa` external classes' secondary
constructors should not have a delegated call, so we
don't create a call if there's no explicit call.
But we need to check if there is.
The failing tests were muted in
`8fcf91d8`, and are now unmuted
back. Those are the ones in the
`testData/rawBuilder/declarations`
folder. These tests fail because they supply
PSI stubs for the secondary constructors,
so arbitrary operations (like reading .text of
the delegated constructor call) are not allowed
for them. This commit modifies secondary
constructor stubs to include the
required information.
^KT-65268 Fixed
Merge-request: KT-MR-13982
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
If an unused setter parameter was replaced with an underscore ('_'),
it had a special name in the stub ('<anonymous parameter 0>'). The text
version of the stub inserted it as is, leading to an extra
'PsiErrorElement'.
^KTIJ-28194 Fixed
The trove4j library is licensed under LGPL, and that causes some troubles while working with it. The fastutil library provides the same functionality in the context of our needs, and is licensed under the Apache license.
^KTI-1135 In Progress
- If the `sealed` modifier is not kept in the interface's stub, a
sealed interface will have an `abstract` modality instead, which
causes issues with `when` exhaustiveness analysis in K2.
- This issue also affected K1, but it was less visible there because
`when` exhaustiveness analysis in K1 uses deserialized descriptors.
^KT-62895
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
This check is used in equivalence check which is symmetric, and
java refers to kotlin through light classes.
LC implementation already contains support for matching
wrapped and origin kotlin members,
both K1 and K2 LC implementations.
Thus, this check is redundant.
Removing it, we cleanup kotlin psi from java psi
It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
- There is no other usage of `AssertionError` in the
`org.jetbrains.kotlin.psi` package. `errorWithAttachment` is more
idiomatic, throws an `Exception` instead of an `Error`, and avoids
leaking user code.
- The exceptions in KT-63130 occur because PSI tree change events may be
published when parts of the PSI under modification are inconsistent.
Such inconsistent elements are then analyzed by
`LLFirDeclarationModificationService` to check if the modification
occurs in a contract statement.
- The solution adds `*OrNull` functions to `KtQualifiedExpression` which
return `null` instead of failing with an exception when the receiver
or selector cannot be found.
^KT-63130 fixed
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
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 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
We can create nested ClassId just from the parent stub instead of calculation by tree.
This commit simplified the complexity of ClassId building to liner.
Example:
```kotlin
package one
class A {
class B {
class C {
class D
}
}
}
```
Previously, we had to create ClassId by traverse parents for each class.
Now we will visit each class only once.
It should improve performance and memory consumption during indexing.
^KTIJ-26848
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
The fixed error leaded to the invalid resolve of methods during
evaluation, e.g. kotlinx.coroutines#runBlocking should be called from
facade BuildersKt instead of BuildersKt__BuildersKt
the script declarations are considered public, at least because they
can be reused from another script then used with the `importedScripts`
configuration property. It also improves the compatibility with K1
scripting.
LL API incremental analysis depends on modification stamps for files and
declarations. Adding an import directive would modify a modification
stamp of an ordinary KtFile. The same should apply to a KtCodeFragment.
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'.
Marco Pennekamp