There are design questions about reflection for adapted references,
so the current proposal is to prohibit reflection on them and support
it properly later
#KT-40406 Fixed
See original logic at org.jetbrains.kotlin.types.expressions.unqualifiedSuper.UnqualifiedSuperKt#resolveUnqualifiedSuperFromExpressionContext
^KT-39070 Fixed
^KT-39599 Related
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.
Don't add `Unit` if variable has an upper constraint T <: A.
It's impossible to coerce variable T to Unit as constraint system will
be always contradictory: T := Unit => Unit should be subtype of A
#KT-39900 Fixed
Before that commit we desugared `a ?: b` as
when (val elvis = a) {
null -> b
else -> elvis
}
It was incorrect, because `a` should be resolved in dependent mode,
but when it was `elvis` initializer it was resolved in independent
mode, so we can't infer type for `a` in some complex cases
- DeprecatedSinceKotlin annotation should only be applicable when
there's `@Deprecated` annotation on the same declaration
- Deprecation level shouldn't be specified in the relevant
`@Deprecated` annotation
- Check that warningSince <= errorSince <= hiddenSince
This annotation will be used in the standard library to prevent the new
compiler from reporting deprecation diagnostics in case an older API
version is used (where the declaration was not deprecated yet).
#KT-23575 Fixed
For Java, they have rather different semantics considering "overrides"
and obtaining functions/properties from supertypes
See the Java statics implementation
The problem was that we didn't incorporate T == Foo into K <: Inv<out T>.
It happened because of optimisation that isn't applicable here as we
already have projection in the initial type
#KT-39777 Fixed
Mikhail Zarechenskiy