See original logic at org.jetbrains.kotlin.types.expressions.unqualifiedSuper.UnqualifiedSuperKt#resolveUnqualifiedSuperFromExpressionContext
^KT-39070 Fixed
^KT-39599 Related
There is no need to update type of delegate expression if it's already
resolved correctly (doesn't include non-proper types). In almost all
cases it was fine except number literals as there we didn't box
expression in backend and got problems at bytecode verification stage
#KT-40057 Fixed
In case of initializing property or function with anonymous object the
object is being exposed outside its field/function's scope and
accessible on previous level. In this case in `declarations only` mode
we have unbound symbols. Fix is to force body/initializer loading in
such cases.
Make sure it is deserialized in `declarations'only` mode too.
- Fix KT-40216
- Add test
This commit handles "subclass: super-interface by delegate-expression".
During Psi2Fir, for each delegate, we add to the subclass a synthetic
field (which has type super-interface), and an assignment of the
delegate-expression to the synthetic field in the primary constructor,
so that the delegate-expression can be resolved and transformed along
the way.
During Fir2Ir, we look up delegatable members from the super-interface
and generate corresponding functions/properties for the subclass.
TODO: support for generic delegatable members and generic
super-interface.
Synthetic property is var when it have setter. The latter is set up
in property when its parameter type is equal to getter return type. In
case of using @Nullable, parameter type of setter is not equal to
return type of getter, because the latter is flexible type. So to fix
this verification should occur using not null types
#KT-39076 Fixed
it during spill-unspill.
Coerce int to boolean, otherwise, VerifyError is thrown on android
Completely rewrite SpilledVariableFieldTypesAnalysis... again,
but this time use BasicInterpreter
This way, the analysis both does not use SourceInterpreter and
is in line with the rest on analyses.
1. Enum entry fields don't have nullability annotations.
2. Enum class special methods (values, valueOf) are not 'final'
(although they probably should be, javac generates corresponding
methods without ACC_FINAL flag).
3. Enum class special methods don't have nullability annotations.
4. Don't generate synthetic accessor for enum entry class constructor.
KT-37019 KT-37020 KT-37021
Denis Zharkov