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'.
It has been marked as deprecated for a while and targeted to be deleted in 1.9.0
#KT-53781
Merge-request: KT-MR-10082
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
The problem results in broken import quick fix and import optimizer on
the IDE side [1].
`AssignResolutionAltererExtension` introduced a possibility to override
resolution of assignment statements. The inconsistency though is
that `KtSimpleNameReference.getResolvesByNames` doesn't return a name
for the overridden `=`. Kotlin as a language doesn't support this [2].
This commit eliminates the drawback above:
1. It fixes the name `assign` the `=` can be resolved to [3].
This eliminates the need to search for the name, bypassing the
plugins.
2. `KtSimpleNameReference.getResolvesByNames` returns `assign` among
other names in case it deals with binary `=` and assignment is
resolved.
3. `KtCompilerPluginsProvider` was extended to check plugins' presence.
K1 implementation added.
----------------------------------------------------------------
[1]: https://youtrack.jetbrains.com/issue/KTIJ-24390
[2]: OperatorConventions.getNameForOperationSymbol
https://kotlinlang.org/docs/operator-overloading.html#augmented-assignments
[3]: OperatorConventions#ASSIGN_METHOD + AssignmentPluginNames
^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
Anna Kozlova