- Reparent declarations in FileClassLowering, InterfaceLowering,
StaticDefaultFunctionsLowering, EnumClassLowering, and
RenameFieldsLowering
- Set correspondingPropertySymbol in MoveCompanionObjectFieldsLowering
- Reparent field initializers in MoveCompanionObjectFieldsLowering and
EnumClassLowering
- Ensure that parents are unique in PropertiesLowering
- Set declaration parent in SharedVariableManager
- Set field declaration parents in CallableReferenceLowering
- Set declaration parents in FunctionNVarargInvokeLowering
- Set declaration parents for external declaration fields
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.
We would like DeclarationDescriptor.getOriginal() to always point to a
(preferably unique) unsubstituted descriptors for the given possibly
substituted descriptor. In case of LazySubstitutingClassDescriptor
(which can be observed for nested generic Java classes), this invariant
was broken, because 'getOriginal()' for constructors of substituted
class returned a copy created for this particular substituted class.
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.
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
Roman Artemev