Condition was too strict if we actually make super call
through super class. Diagnostic is redundant cause there isn't breaking
change depending on interface method generation strategy.
This can happen e.g. if all supertypes were on the cycle (A : B, B : A)
-- then SupertypesLoopChecker will cut all supertypes that are on cycle,
leaving set of supertypes empty.
Some clients in the compiler are not ready to work with empty list of
supertypes -- notably, CommonSupertypes.
^KT-23029 Fixed
Private suspend functions need to be generated as package-local, since
they are called from their continuations.
However, this means that they can be called from Java, which breaks
their private visibility.
Adding synthetic to them fixes the issue.
#KT-17584: Fixed
Do not mix ScriptDependenciesInfo for all project and for concrete script.
Rename ScriptDependenciesModuleInfo to ScriptDependenciesInfo
Rename ScriptDependenciesModuleSourceInfo to ScriptDependenciesSourceInfo
We're suspecting that the culprit of such errors is race condition on
'supertypes' in AbstractTypeConstructor, when it is created using
'LockBasedStorageManager.NO_LOCKS'
- Do not longer call hashCode on java/lang/Object but do this
on statically checked type.
- Do not longer call Intrinsics.areEqual but use directly
equals method on statically checked type.
Fix of https://youtrack.jetbrains.com/issue/KT-12330
For some reason there were ~1000 tests that were spontaneously
falling (~20%) because they couldn't find some class. It was mostly
Java classes.
Those failures started after cff88a3f8b.
There were group of commits about notifications right before it:
b4fb0e0305b77a0caa83d34edac3253b7d8e082b..1be33b91fa85e50f5048dc5a12604debfa3c19e8
#KT-23399 Fixed
Treat them like lambdas. This means:
1) Like local suspend lambdas, which become "non-suspend" after creating
jvmSuspendView, they do this as well
2) They both are generated with the same codegen.
3) They are treated differently only on front-end side.
#KT-20364: Fixed
Mikhael Bogdanov