In short, some of the bytecode analyzers assume that there could be
no stores instructions into parameter vars with value of different
types (even when the value type is a subtype)
See the issue for details
#KT-19713 Fixed
So (for the most often reproduction case) #KT-19433 Fixed
Before this commit, internal names for nested classes were written as test/Foo/Bar (comparing to test/Foo$Bar in the normal mode), as getting qualified names from such internal names was trivial. But, because of IC, we needed to write class files to the disk, so our decompiler could find such "broken" classes and read it in a wrong way.
This happens when we resolve bounds for type parameters, causing wrong
UPPER_BOUND_VIOLATED to be reported on type parameter whose bounds were
not resolved yet.
#KT-19601 Fixed Target versions 1.1.5
Prior to the 1.1.4, nullability related annotations were stored
in types that became hard to maintain at some moment and
we got rid of it (see 57b7b91444)
But enhancement for properties overrides stopped working
because there were effectively no annotations in the
resulting descriptor
#KT-19409 Fixed
#KT-19409 Fixed
FixStack transformation divides on phases:
- Fixing stack before break/continue
- Fixing stack for inline markers/try-catch blocks
After the first stage all ALWAYS_TRUE markers are replaced
with simple GOTO's and if we're skipping break/continue edges
we won't reach the code after while (true) statement.
At the same time it's fine to not to skip them in the second phase
as the stack for them is already corrected in the first phase
#KT-19475 Fixed
Note that this isn't fully correct, consider the following situation:
S : T, T : Any?
=> CS(S, T) = T, but for now it will be T?, which is reliable but not so specific as just T
It's more consistent to normal function body for IDE.
Doc comments in file beginning are now sticks to declarations
correctly.
Moving declarations at the end of scripts is fixed
Problem manifests when a class property name matches a companion object
property name, and class property is referenced in closure context.
#KT-19367 Fixed Target versions 1.1.5
Also, require users of K2MetadataCompiler to pass "-Xmulti-platform"
manually. Gradle and Maven plugins already do that, so only users who
invoke kotlinc directly are going to be affected by this
#KT-19287 Fixed