Currently kotlin-stdlib-common doesn't have serialized built-ins inside,
so in a multiplatform project, it was possible that either JVM or JS
built-ins (depending on the order of entries in the project
configuration) were going to be used for the analysis of a common module
depending on kotlin-stdlib-common. This resulted, for example, in
additional built-in member calls (e.g. "List.stream()") being unresolved
in JVM modules when they used the List instance coming from the common
module (see the added test)
Now it's possible to do find usages for other languages when light
elements are used.
Revert efb36f4a49 and revise fix of KT-7983:
Don't consider local and non-local class with same fqn equivalent.
#KT-7983 Fixed
Set test directory to directory with test files (not relative to
findUsages folder). This way test will be configured as if all testdata
is under source root (previously it was copied into package under path
with findUsages) and resolvers will see classes under root package.
#KT-14974 In Progress
Applying plugins leads to failures when matching members in LazyLightClassDataHolder
because plugins rely on analysis results
This decision has its drawbacks (java won't see results of plugin execution)
but more work on light classes is needed if we want to support this usecase
We can argue that plugins should only generate synthetic members
but there is no such restriction atm
Otherwise any cached reference to light class can lead to severe memory leaks in IDE
since LightClassBuiderResult holds GenerationState which holds ModuleDescriptor
Introduce system property kotlin.compiler.X.enable.idea.logger=true
The reason is that I suspect that the error is somewhere at com.intellij.ide.plugins.PluginManagerCore#loadDescriptorFromJar but unfortunately default logger doesn't log messages at "info" log level so we can't see why exactly does it fail.
Users can enable IDEA's logger to see more details.
Don't use coroutine facade in following cases:
* When calling coroutine functions in non-suspend mode (i.e.
suspend flag is either false or skipped).
* When passing continuation from suspend function to suspend function.
Use facade only for corresponding intrinsics.
Reason: interceptor should not be called on each suspend function
invocation, it should be called after resume from innermost
suspend function.
Fix KT-17067. The example provided with the issue is very similar to
dispatchResume.kt which passes after these changes.
Add test to prove that KT-17446 is no more reproducible.
Dmitry Jemerov