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.
Instead of reusing the same AnalyzerFacade that is used for resolution
of a module to resolve its dependencies, analyze each dependency
module/library with a facade depending on its target platform. Introduce
and use CommonLibraryDetectionUtil in addition to
KotlinJavaScriptLibraryDetectionUtil, to detect common libraries (with
.kotlin_metadata files).
Note that before multi-platform projects, this was not needed because
there were only two platforms (JVM and JS), and JVM module had only JVM
modules/libraries as dependencies, JS module had only JS
modules/libraries as dependencies. Now, for example, a JVM module can
have a common module/library as a dependency, and it would be incorrect
to analyze that dependency with JvmAnalyzerFacade because that facade
does not know anything about .kotlin_metadata files.
The changes in Dsl.kt and KotlinCacheServiceImpl.kt are needed because
PsiElement.getJavaDescriptorResolver, called from some IDE code, started
to fail on a common module, because the container for a common module
does not have the JavaDescriptorResolver
When resolving a class body for a class without a primary constructor
(e.g., an interface), no checks were performed for redeclarations
in the corresponding class header.
Creating & initializing a lexical scope of an appropriate kind will do it.
Note that since class has no primary constructor, only type parameters
could be redeclared (and that's KT-4960).
Stop making aliasing suspend function descriptor with reference to
instance of state machine. This may cause problems in some cases,
for example, when compiling recursive suspend function. See KT-17281.
Instead, make alias for synthetic continuation parameter. This
additionally required some refactoring, e.g. *always* generating
continuation parameter during codegen.
Codegen generates clean instructions for ref values (captured vars)
on block exit so we should delete them on dereferencing captured values.
#KT-17200 FIXED
Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
Produce special stdlib artifact with annotations for dist.
Put js outputs to dist, they're required for JS backend tests.
Use kotlin-compiler for maven, which has all required dependencies bundled.
Clean local directory repository on clean.
Change paths in tests to compiled artifacts.
Note that there are some other problems, for example:
`val a = if (true) 1 as Number else 2`, here we'll get useless cast
#KT-9551 Fixed
#KT-9645 Fixed
As "java" does, do not include the current directory to the classpath if
the explicit classpath is specified. This is more stable than always
adding the current directory, and users can easily add the ".:" to the
beginning of the explicit classpath themselves
#KT-17100 Fixed
Anonymous classes for local function references implement their
getOwner() as "return null" currently (KT-14291). To avoid NPE in this
case, we now consider two local functions the same if their name and
signature are equal. This is incorrect in general, but unlikely to cause
major problems and is going to be fixed by KT-14291 eventually anyway
#KT-17055
The directive was only used in this test and it had no effect on the
behavior of the test. The test is removed because it's equivalent to
simple.kt in the same directory
Zalim Bashorov