Otherwise, when completing all the unsuccessfull candiates,
resolution of each lambda-arguments starts repeatedly for each candidate
that leads to exponential time
NB: Changes in `completeArguments` are necessary because otherwise
nested lambdas will be analyzed twice:
once for the main resolved call, and then for all candidates
that again leads to exponential complexity
#KT-16672 Fixed
#KT-19457 Fixed
Note that the quick fix to implement header class works incorrectly when
that class has nested classes at the moment; this should be fixed
separately
#KT-15494 Fixed
#KT-18573 Fixed
Also support a quick fix to add 'impl' modifier (KT-18454), although it
doesn't work yet on classes because there's no error on them in the IDE
#KT-18087 Fixed
#KT-18452 Fixed
#KT-18454
Try to report most of the errors on the actual members of the impl
class. In many cases, there's a 1:1 mapping of header to impl class
members, so the error "some members are not implemented" on the class
declaration itself is redundant. Exceptions include functions/properties
from supertypes (there may be no other place to report a signature
mismatch error in this case), functions/properties not marked with
'impl' (the checker is only run for declarations explicitly marked with
'impl') and default constructors (the checker is not run for them)
#KT-18447 Fixed
Try to report most mismatch errors on the 'impl' declaration. Only
report a mismatch error on the 'header' declaration if no error would be
otherwise reported on any 'impl' declaration in the compilation unit.
Also render declaration kind in the message
#KT-18447 In Progress
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
Alexander Udalov