Added creation and initialization of the test module and its dependencies.
When looking at the emptyProgression test,
I found that getProgressionLastElement was not found,
which should be resolved from the dependencies.
Without this commit, JVM name mapping logic in BE does not work for FIR,
because FIR cannot use old BuiltInsPackageFragmentImpl descriptor.
In this commit we add our own implementation thus fixing
a pack of FIR black box tests.
1. Search for increment function in range element type, not in inferred
induction variable type
(which can be inappropriate, e.g., 'Nothing' in case of 'continue').
2. Handle nested loops with shared exit labels
(generated by JVM_IR for KT-37370 case).
KT-37370 KT-37373
This commit addresses the following issues:
* accessors didn't take into account their property's receiver type,
which caused NoSuchMethod due to signature mismatch. Now the property's
receiver type is passed to Fir2Ir translation of accessors.
* property's parent was not class, e.g., kotlin.collections.indices.
Now the symbol table collects WrappedPropertyDescriptorWithContainerSource
besides WrappedFunctionDescriptorWithContainerSource, so that
facade classes for such properties can be generated before codegen.
* accessor's parent was not class. Now the containerSource of
the property descriptor is passed to accessor descriptor.
Library methods such as 'listOf' are resolved
to have the package fragments as their parents,
but JVM expects their containing file classes as parents.
This fix generates those file classes and
uses them as parent replacements for such library methods.
Before this commit we had two statements blocks for 'for' loops:
range variable declaration + iterator variable declaration + while loop.
However, BE requires a bit different loop structure to make lowerings
properly so in this commit iterator declaration & while loop were
extracted to separate block.
Don't insert implicit null check on a value of @EnhancedNullability type
used where @EnhancedNullability type is expected.
This uncovers a bunch of other problems in FE and BE.
KT-36343 and KT-36347 are bugs in StrictJavaNullabilityAssertions
implementation which should most likely be fixed in next major language
version (with proper breaking change notice).
KT-36344 is a design problem which should be addressed after 1.4 issues
are resolved.
This commit fixes two issues in the existing implementation of translating primitive array types:
* IrType.getArrayElementType throws an exception when the receiver is a primitive array type, because IR expects primitive array types use symbols defined in IrBuiltIns, but fir2ir translation doesn't;
* IteratorNext.toCallable assumes all element types are boxed.
The first issue is fixed by changing the fir2ir type translation to use symbols in IrBuiltIns for primitive array types, and the second by not unboxing primitive types.
Alternatively, we could improve the lookup utilities and their usages to
always find the exact override of a symbol from
Collection/Iterable/CharSequence/etc, but since we need to load the
original symbol anyway in cases when the loop subject's type is a type
parameter, we might as well simplify everything and always reference the
original symbol.
Also improve exception message and removed unused declarations in
IrBackendUtils.kt.
last-exclusive progressions (i.e., "until" progressions and loop over
array indices).
This change makes it possible to correctly implement the handling of
"step" progressions. Computing the last element of a stepped progression
requires that the last is inclusive.
Also invert the while loop (into if + do-while) that is used when
lowering for-loops over progressions that cannot overflow. This keeps
the performance characteristics closer to the ForLoopsLowering in
kotlin-native, since the goal is to converge to this shared version.
Also used IrType instead of KotlinType, where possible.
https://github.com/JetBrains/kotlin/pull/2390https://github.com/JetBrains/kotlin/pull/2305
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.
We get the info for the underlying progression and invert it. For
progressions whose last bound was open (e.g., `until` loop), the
reversed version will have an open first bound and so the induction
variable must be incremented first.
Also unified the way of extracting HeaderInfo out of changed calls
(e.g., `indices.reversed()`), and fixed declaration parents in
ForLoopsLowering.
HeaderInfo object, and modifying the operator in the loop condition.
The "additional emptiness condition" is no longer necessary with this.
The open/closed property was removed from HeaderInfo in an earlier
commit, but bringing it back in to simplify the loop building makes
more sense.
Also expanded tests for evaluation order of range bounds.
Juan Chen