IrConstructorCall gets type parameters from the class in addition to the
constructor declaration. This behavior is already implemented for
ClassConstructorDescriptorImpl, but was not implemented for
WrappedClassConstructorDescriptor, leading to missing type arguments for calls
to constructors generated in a lowering pass.
The comment in the code is correct that EnclosingMethod
attributes should only be generated for local and
anonymous classes. We were generating them for member
classes as well which leads to invalid class files.
With this change I had to mute one more tests. That is
because we lose the parent method and therefore we
see a class as a member class instead of a local class.
With the old descriptor based check that test still
passes.
Remove "JVM_TARGET: 1.6" directive from box tests and remove tests with
JVM target 1.8. By default, box tests are run with JVM target 1.6, and
there's an additional configuration `codegenTarget8Jvm8Test` that runs
all box tests with JVM target 1.8.
Also, remove box tests with JVM target 1.6. They aren't needed because
even if we manage to generate incorrect bytecode with target 1.6, the
corresponding box tests will catch that
This change also makes sure that no line numbers are generated
in the wrappers in the JVM_IR backend.
Change-Id: If6c37f8a20894455abddb526039df059e02015a3
unsigned ranges/progressions.
The tests pass in JVM_IR for signed, but fail for unsigned due to
inlining being broken. We can disable the JVM_IR tests for unsigned,
while keeping them enabled for signed, to get better test coverage in
the interim until inlining is fixed.
Current implementation of calls with super qualifier relies on
invokespecial, which has some more constraints than regular virtual
invocations. When those constraints aren't met, accessors are needed.
There was a silly bug: equal constraint is actually a lower and an upper
constraint, but we checked only presence of lower constraints.
Test is important as here we have one equal constraint and should
complete inner call `foo<Int>()` without propagating it to `bar` to
avoid using `NoInfer` annotation multiple times
There is an inconsistency between old and new inference for storing
receivers of resolved calls. In new inference, for captured types,
receiver will be changed and to preserve behavior of the old inference,
we use original one during important checks.
This is more a workaround than a solution and should be revisited.
#KT-31356 Fixed
#KT-29948 Fixed
#KT-31360 Fixed
Ting-Yuan Huang