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.
do-while with enclosing "not empty" check).
Also do not add additional "not empty" condition for `until` loops when
the given bound is a constant != MIN_VALUE.
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.)
Since we skipped trivial constraint with `Any?` from parameter type of
function `equals`, the compiler thought that there is no proper
constraints (upper bounds do not matter here) and marked resolved
call as a failed one, then diagnostic about missing equals was added
Also, tune `TrivialConstraintTypeInferenceOracle` for `Any?`-like
constraints
#KT-30724 Fixed
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
These tests were added for suspend-conversions, it worked only
with new inference, but implementation was incorrect and had other
bugs, which were fixed in 1ac25259.
Support of suspend-conversions will be addressed later with a different
implementation (#KT-30703)
After cold stream related fixes, we do not generate state machine until
the very last transformation of the lambda. Thus, it is safe to
generate debug metadata for that lambda.
#KT-30694 Fixed
Mikhail Glukhikh