Otherwise, we have a static initialization loop, leading to null-leaks
Removing default interface method indeed disconnects the loop, as per JVM
Specification, "5.5 Initialization".
See KT-33245 for detailed explanations
^KT-33245 Fixed
This is required in case when NpmSimpleLinker works (instead of yarn).
NpmSimpleLinker will not produce yarn.lock file, so :kotlinNpmInstall
was always up-to-date. Adding fake state file fixes the problem.
#KT-32874 Fixed
Previously it was linear scan, failing on unbalanced suspension markers.
Now, I use CFG to find end markers, which are reachable from start
markers. Using CFG allows to walk through suspension point instructions
only, since they form region.
If, for some reason, end marker does not exist (inliner or unreachable
code elimination pass remove unreachable code) or is unreachable,
just ignore the whole suspension point, as before.
#KT-33172 Fixed
#KT-28507 Fixed
Useful for tests that check behavior which depends on having a recent
API version enabled, and that don't want to depend on a specific fixed
API version (to prevent eventual obsoletion)
To mimic the case of user passing an explicit "-api-version" flag to
avoid API version being inferred to the version of stdlib in
dependencies by JvmRuntimeVersionsConsistencyChecker
We're going to start using this method since 1.4 for parameter null
checks, and without this change the compiler would fail if it
encountered a call to such method on a lambda parameter inside an inline
function, since that call is not inlinable.
#KT-22275 In Progress
Note: we have to print captured types for lambda parameters.
It is needed for nullability inference as it requires explicit types specification to work.
Later in post-processing we remove explicit type specifications for lambda parameters which have captured types
#KT-33186 fixed
previously for instance `KtClassBody` could get here as `leaf` and `leaf.parent` will return `KtClass` for it, making gutter for `KtClass` appear twice if origingal identifier and `KtClassBody` got here in different passes (one in "inner" other in "outer")
Relates to KT-8834, we continue reducing differences between old and new
inference. Note that as for `SamConversionPerArgument`, this feature
is enabled in the compiler and not in the IDE to avoid breaking code
for those users that already enabled new inference in the compiler
We've found that the BindingContext is necessary for any meaningful suppressor.
This change adds the ability for suppressors to use the BindingContext when available.
Change-Id: I14d8148ef659eca273445bf0638bcdb8c3b21f02
When using dummy resolving for creating stubs of data classes we do not have overriding information
which is needed to determine whether we need to generate synthetic members or not.
As a result of that, we may have two different versions of member scope: the first one is
resolved by dummy resolving and the second one resolved via an ordinary one.
As light methods depend on the index of them in the class body,
we can have two different methods with the same index
which breaks mapping from dummy resolved methods to normal ones.
This behaviour can be reproduced when having data class which
extends other class with some synthetic members overridden and marked as final
like described in #KT-32969
#KT-32969 fixed
Igor Chevdar