- 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
Move kotlin-stdlib-js project and the sources specific to the current backend to 'stdlib/js-v1' directory,
but leave sources that can be shared with the new IR backend in the common 'stdlib/js' location
with exception for 'stdlib/js/src/generated', which is used exclusively for current backend.
This simplifies sourceset configuration when building stdlib with the new backend.
The type mapper does not map enum parameters and outer this parameters
to the right parameter signature kinds so around half the tests
are still failing. Since a new type mapper is being worked
on I will not investigate that further right now.
The reference can be lowered to `this` if it is captured in the lexical
scope of the corresponding enum entry, and not used by the enum entry's
super constructor. Otherwise, it is lowered to
`GETFIELD SomeEnum.SomeEntry`.
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.
This works in many cases, however, it is incomplete since there
are cases where classes are extracted to top-level and therefore
reparented. Therefore, we lose the information about the function
class are nested inside.
Two known issues with generateNonPartClassDeclarations that was here
before were the fact that we didn't sort sealed classes and its
subclasses which led to NoSuchMethodError (KT-27097), and the fact that
we didn't skip expect classes which led to incorrect duplicate JVM class
name diagnostic (KT-30843)
#KT-27097 Fixed
#KT-30843 Fixed
The KotlinType.toIrType function sometimes produces unbound symbols
and was only used in IrIntrinsicFunction and SharedVariablesManager.
This change removes the broken function and changes SharedVariableManager
to use IrType consistently and IrIntrinsicFunction to use KotlinType
consistently.
Steven Schäfer