non-specialized progressions, including "step" progressions.
DefaultProgressionHandler uses the "first/last/step" properties of
the progression when building the loop header.
ForLoopHeader, instead assuming that all ranges are closed and that the
"last" property is already property calculated.
This means the HeaderInfo.last for arrays, "indices" and "until"
progressions are decremented from the bound. This simplifies the loop
construction and moves the work to the handlers. This will also simplify
the handling of "reversed()" in the future since we don't need to
consider the case where the lower bound is open.
ForLoopHeader base class.
These terms are less loaded and less confusing, especially with "downTo"
progressions, and once we start handling "reversed()".
the step expression.
The semantics of "step" are now clearer: It will no longer be negated
based on the "increasing" property; if the progression is decreasing
(i.e., for "downTo" progressions), then it must be negative. The
"increasing" property is still used when building the emptiness
condition.
Also deleted StepHandler. Since the HeaderInfo.needLastCalculation is
only set to true for handling step progressions, deleted that property
and all associated logic around it.
Diffs resulting from the port:
https://github.com/punzki/kotlin-native/compare/master...punzki:for-loop-diff
When ForLoopsLowering is added to the JVM lowering phases, this causes some of the forLoop bytecode tests to pass, and many still fail due to differences in behavior compared to non-IR backend:
- Generated conditions for lowered loop
- Generated temporary variables
- Supported iterables (e.g., withIndex(), CharSequences)
- Means of incrementing induction variable
The phase will be added once more TODOs are resolved and it is more functionally complete, to prevent breaking for loops.
Previously,
* Equals performs IEEE 754 equality check for floating points and
byte-to-byte checks for other types, including references.
* Ieee754Equals performs IEEE 754 for primitive types
* TotalOrderEquals performs total order equals to all types, including
floating points.
Now it is simplified,
* Equals performs total order checks for all types.
* Ieee754Equals performs IEEE 754 for primitive types.
* (TotalOrderEquals is removed.)
Cleanup TypeConstructors & KotlinTypes in VariableFixationFinder
Cleanup TypeConstructors & KotlinTypes in TypeVariableDirectionCalculator
Cleanup KotlinTypes in TypeCheckerContext for ConstraintSystem
Cleanup KotlinTypes in NewCommonSuperTypeCalculator
Cleanup KotlinTypes in TypeApproximator
Cleanup type substitution
Cleanup NewTypeVariable
Cleanup StubType
Cleanup TypeCheckerContext creation, extract common supertype context
Provide TypeSystemInferenceExtensionContext via dependency injection
Java constructors can have type parameters of their own:
public class J<X extends Number> {
public <Y extends CharSequence> J() {}
}
When such constructors are called from Kotlin, type parameters for
constructor follow type parameters for class:
fun test() = J<Int, String>() // <X=Int, Y=String>
Descriptor-based representation uses the same type parameters ordering.
Also, use 'withScope' in IrLazyFunction type parameters creation.
This removes the mandatory dependency of all JVM IR tests on
kotlin-stdlib (ConfigurationKind.ALL in all IR test cases) and speeds up
tests which don't need kotiln-stdlib by about 20%. Another advantage of
this method is that all required dependencies are listed in one file,
are easy to grasp, and changes to the related code generation can be
done independently of the corresponding changes in the actual library,
which may help in bootstrapping the compiler
All call sites of this method construct parameters with the given string
literal name (and more such call sites are coming in subsequent commits)
and it feels like a boilerplate to wrap it into Name each time manually
Default type is `KProperty<R>` where R is KProperty's type parameter.
This type doesn't make much sense outside the KProperty's own class
declaration. A more correct type here is `KProperty<*>`, which is the
type used in property delegates in Kotlin
* In blocks, discard the result of any statement that has a return
type other than void. This was previously done by wrapping each
statement into an "implicit Unit conversion" that was actually
compiled down to a stack pop instead. If an expression happened to
already have type Unit, however, such a conversion was not inserted,
resulting in a stray reference on the stack. These conversions are
now redundant and should probably be removed.
* In assignments and non-exhaustive conditionals, materialize a Unit
on the stack to avoid depth mismatches that trip up the bytecode
validator. Because such expressions are generally used at block level
(and, indeed, the frontend will reject a non-exhaustive conditional
used as an expression), combined with the above change this results
in no additional GETSTATIC opcodes, as they are immediately removed
by the peephole optimizer.
Mark Punzalan