To create a smart psi type pointer, IJ Platform uses resolve.
We cannot use resolve from JavaSymbolProvider, as it may lead to resolve contract violation.
^KT-59133 fixed
KtResolveExtensions are designed to handle IDE analysis use cases where
source might not be available at analysis time, because that source is
generated by an external source generator, such as an annotation
processor or resource compiler. The sources generated by those external
generators can appear in the analysis scope, and cause issues with
source clash - resolution may find the virtual source from the
KtResolveExtension, the on-disk generated source from the external
generator, or both. This can cause issues, because that on-disk
generated source may be stale, and may not have symbols that will exist
the next time the generator is run (or, conversely, may have symbols
that will disappear on the next build).
To solve this, add a `getShadowedScope(): GlobalSearchScope` to
`KtResolveExtension`. Any files in the module that are included in that
scope will be hidden from resolution, allowing the resolve extension to
cleanly replace those files.
^KT-58834 fixed
It's very slow and leads to performance problems (see KT-58125)
Instead, we do the following:
- For a fully resolved type qualifier, when we want to resolve its part,
we are looking for the corresponding symbol by traversing nested classes
bottom up.
- For an error qualifier, we are trying to resolve the maximum possible
qualifier in the types transformer where all the type scopes are
already available.
^KT-58125 fixed
The issue appeared after code refactoring. Originally we didn't
save generated accessor for symbols in `IrFunctionReference`. These
symbols will be processed in their own turn.
#KT-59079 Fixed
It was happening because for MyClass.foo we didn't set overriddenSymbols
properly because in ClassMemberGenerator.convertFunctionContent we
used incorrect containingFirClass that was pointing to anonymous class
instead of MyClass.
^KT-58902 Fixed
- try to find sources for decompiled symbols in IDE mode
- function literals can't be declared as extensions,
though there target can contain that indication,
let's take what descriptor provides
Still supported IDEA/Kotlin plugin releases relies on
'kotlin-annotation-processing-gradle' artifact name in compiler plugins
classpath. I've restored this publication usage until we will stop
support Kotlin plugin versions that doesn't know about
'kotlin-annotation-processing-embeddable' name.
^KTIJ-25586 Fixed
Those are dependencies that point back to the original project.
This can happen with two projects like
```
// project a
kotlin {
commonMain.get().dependencies {
api(project(":b"))
}
}
// project b
kotlin {
commonTest.get().dependencies {
implementation(project(":a"))
}
}
```
Where b(test) -> a -> b
^KT-59020 Verification Pending
Currently, if a Kotlin object happens to have null for an associated
object but FLAGS_RELEASE_ON_MAIN_QUEUE flag set, GC will dispatch
Kotlin_ObjCExport_releaseAssociatedObject(null) to the main thread
anyway.
This couldn't happen before, but can now, with disposeObjCObject.
The commit prevents this, by moving the null check out from
Kotlin_ObjCExport_releaseAssociatedObject to call sites.
^KT-59134
For a Kotlin wrapper of an Objective-C object, this functions zeroes
and releases the strong reference from the Kotlin wrapper to the
Objective-C object.
Usually, such a release happens only when the Kotlin wrapper is GCed.
So using this function can help that happen sooner.
^KT-59134
Ilya Goncharov