Putting them in the local variable table means that the debugger
needs to have special handling for parameters with specific names.
That forces us to generate mangled names for these.
Instead of also implementing the name mangling for FIR, this
change gets rid of the parameters from the LVT instead.
The steps of psi2ir and JVM backend need to be separated in the API
because in case of cyclic module dependencies (which are allowed in JPS)
psi2ir should be run first on all sources, and then JVM backend on each
module separately. `CodegenFactory.convertToIr` does nothing in the old
backend.
Also, move the ignoreErrors to GenerationState for simplicity.
#KT-48177 fixed
the issue is in fact fixed by the previous commit (report error
on duplicated import) by normalizing import path before processing,
but here we're making error reporting nicer for the case.
We are working on a feature in the Kotlin Gradle plugin called
`kotlin.incremental.useClasspathSnapshot` to improve incremental
Kotlin compilation.
In this feature, we need to extract ABI information from a .class file.
If the .class file is a Kotlin class, this info can be found in the
class header data. But if the .class file is a Java class, this info is
not readily available.
The RuntimeModuleData class in the ':core:descriptors.runtime' project
can help with that: It uses reflection to generate `ClassDescriptor`s.
However, reflection requires a full classpath to work correctly, whereas
we want to generate a `ClassDescriptor` directly for each class file
(also, reflection is probably slow).
To address that, this commit refactors RuntimeModuleData so that it can
support a generic Kotlin/JavaClassFinder, which can be based on either
reflection or bytecode analysis. The existing code continues to use
reflection while the new feature will use bytecode analysis (e.g., using
the existing BinaryJavaClass).
Bug: KT-45777
Test: Existing tests should pass (this is a refactoring-only change)
Kotlin plugin sources were migrated to intellij-community:
https://github.com/JetBrains/intellij-community/tree/master/plugins/kotlin
Preserve `jps-plugin/testData/incremental`
because it's used in `compiler/incremental-compilation-impl/test`
Preserve `idea/testData/multiModuleHighlighting/multiplatform`
because it's used in `MppHighlightingTestDataWithGradleIT`
the dependency on the coroutines library caused various problems like
KT-30778, or stdlib/runtime version conflicts.
The only function used was `runBlocking`, so this change replaces it
with the internal implementation based on the similar internal thing
from the stdlib.
#KT-30778 fixed
Originally, we though that we would move classes from `ide-common` from Kotlin plugin to this
module but it turns that these classes are heavily used in Kotlin plugin and it's better to
keep them with the rest of Kotlin plugin. So now classes in `scripting-ide-common` are copy-pasted
I want to be able to use this function in `:kotlin-scripting-ide-common` & `frontend-independent`
This commit also allows to remove copy-pasted `findLabelAndCall` in `scripting-ide-services` module
During code completion, ShadowedDeclarationsFilter resolves many
synthetic calls (sometimes >1000 for certain projects/scenarios).
By ignoring diagnostics we can avoid running call checkers
during this process (pending a sibling change in the compiler).
Relates to KT-44276 and github.com/JetBrains/kotlin/pull/4027
If there are multiple copies of the same library on the classpath,
then ShadowedDeclarationsFilter becomes very slow because it
encounters many equal-signature declarations and thus has to resolve
a lot of calls in order to pick among them.
Having multiple copies of the same library on the classpath is
somewhat common in real-world projects. It occurs in the
JetBrains/intellij-kotlin project, for example. In that project,
ShadowedDeclarationsFilter ends up resolving thousands of calls,
accounting for around 80% of completion time when there are
many completion results (see KT-44276).
We can optimize ShadowedDeclarationsFilter by checking whether the
descriptors in an equal-signature group are structurally equivalent.
If they are, we can just pick one rather than running resolve.
Testing on a small project with Kotlin stdlib duplicated on the
classpath, this change reduces overhead in ShadowedDeclarationsFilter
from 1200 ms to 20 ms when running completion on the prefix 'a'.
End-to-end completion time is cut in half.
Test: JvmBasicCompletionTestGenerated.Common.Shadowing
Receiver of a function call '<receiver>.foo()' (where receiver is a
class/object/alias name) might be specified incorrectly - corresponding
[companion] object might not be declared.
Before this commit '<receiver>' was considered to be undefined (null).
As a consequence, import suggestion included all 'foo()' functions from
the search scope.
Now as a value of '<receiver>' we set class/object/alias itself
resulting in an empty import suggestion list.
See org/jetbrains/kotlin/idea/util/CallType.kt:307
(#extractReceiverTypeFrom(descriptor: ClassDescriptor)).
Mads Ager