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
NB: The test data change at testData/diagnostics/tests/typealias/noApproximationInTypeAliasArgumentSubstitution.fir.kt
is correct: see the relevant non-fir test, the call shouldn't be applicable
^KT-39008 Fixed
It would allow ConeKotlinType.scope return FirTypeScope
and thus pulling down org.jetbrains.kotlin.fir.scopes.FirScope#processOverriddenFunctions
(See the following commits)
This issue appeared after recently added new overload for flatMapTo.
Before that, we picked candidate returning List<T> and completed
inference, now we also check one more flatMapTo, which is here is
incorrect and as a result we go into outer scope. Outer scope contains
one property with deferred type, which introduced error about
"typechecker has run into recursive problem" even it isn't applicable
by receiver.
So, the fix is to check receiver first and only then check return
type of a candidate.
#KT-39470 Fixed
Mikhail Zarechenskiy