The compiler should only report diagnostics for
comparisons over builtins and identity-less types,
other incompatibilities should be reported
via inspections.
It's ok that in `equalityChecksOnIntegerTypes`
instead of `EQUALITY_NOT_APPLICABLE_WARNING` we get
`EQUALITY_NOT_APPLICABLE`, because
`ProperEqualityChecksInBuilderInferenceCalls`
is already active by default.
This change also replaces the notion of a representative superclass
with the least upper bound.
This makes complex types like
intersection/flexible transparent to
RULES1-based compatibility checks.
One way to look at it is to think
that this is an automatic way of handling
type parameters: automatic picking of
"interesting" bounds, and checking them against one another.
Note that `TypeIntersector.intersectTypes`
for `Int` and `T` where `T` is a type parameter
may return both `{Int & T}` or `null`
depending on `T`-s bounds. At the same time,
for type parameters `T` and `K` it will
always return `{T & K}`.
`ConeTypeIntersector.intersectTypes`, on the
other hand, will always return `{Int & T}`
irrespectively of the bounds. Meaning, the two
intersectors differ in corner cases.
`lowerBoundIfFlexible` call in `isLiterallyTypeParameter` is backed by
the `equalityOfFlexibleTypeParameters` test.
^KT-35134 #fixed-in-k2
^KT-22499 #fixed-in-k2
^KT-46383 #fixed-in-k2
The only case when behavior is change is described at
computeNonTrivialTypeArgumentForScopeSubstitutor
The idea is to avoid depending on the presence of @UnsafeVariance
and instead approximate captured types in covariant argument positions
before building substitution scopes
It's correct because for Captured(*) <: Supertype,
Out<Captured(*)> <: Out<Supertype> and when we've got @UnsafeVariance
value parameters at Out, it's ok to allow passing Supertype there.
^KT-57602 Fixed
^KT-54894 Fixed
The expression needs to be resolved first to determine if there is a
receiver that needs to be extracted to a temporary variable. Also, the
special case for prefix increment/decrement on local variable without
delegates requires resolution to check if the variable is local.
^KT-56771 Fixed
^KT-56659 Fixed
If an annotation doesn't specify an explicit use-site target,
previously it was added to both, the primary constructor value parameter
and the property in the FIR. Then, in FIR2IR, only the "correct" one was
added to the IR. Move up the deduplication logic into the frontend.
^KT-56177 Fixed
```
open class Base<T> {
fun foo(): T = ...
}
class Derived<T> : Base<T> {
override fun foo(): T = ...
}
```
In intersection scope of type `Base<T> & Other<R>` we should create
intersection override based on `Base.foo(): T` and `Derived.foo(): R`
at the same time, despite the fact that `Derived.foo` actually directly
overrides `Base.foo`
^KT-56722 Fixed
- KT-56505 occurred because `source.getChild(KtNodeTypes.MODIFIER_LIST)`
returns any modifier list in the subtree of the source element, not
necessarily the modifier list belonging to the checked element.
`depth = 1` restricts the search to the modifier list belonging to the
checked element itself.
- For example, given `f1` from KT-56505, `getChild` would return the
modifier list of `public var foo = 0`. Because it contains a
visibility modifier, `f1` wasn't marked with
`NO_EXPLICIT_VISIBILITY_IN_API_MODE`.
^KT-56505 fixed
- In explicit API mode, the `public` visibility modifier is not
redundant unless a declaration is hidden by a container. The
`REDUNDANT_VISIBILITY_MODIFIER` diagnostic is now not reported in such
cases.
^KTIJ-24485 fixed
- `REDUNDANT_MODIFIER_FOR_TARGET` is already reported for `open`
interfaces, but for consistency and IDE support, the compiler now
reports `REDUNDANT_MODALITY_MODIFIER` as well via the extended
checker.
- `REDUNDANT_MODIFIER_FOR_TARGET` cannot be disabled for this case
because it's reported via a basic checker while
`REDUNDANT_MODALITY_MODIFIER` is reported via an extended checker.
- Rename `implicitModality` to `redundantModalities` and return a set of
modalities. The idea of a *single* implicit/redundant modality doesn't
stand up to scrutiny. For example, for interfaces with `ABSTRACT`
implicit modality, `OPEN` is also a redundant modifier. But this is
not necessarily the case for all kinds of declarations.
Hypothetically, if it was possible to declare a class that is abstract
by default, adding an `open` modifier to that class would not be
redundant, as it would make the class instantiable.
Namely, do not choose `Nothing?` result type when fixing a variable
that has other constraints besides the ones that came from
the relevant type parameter's upper bounds.
See more details in KT-55691.
In K1, the case from specialCallWithMaterializeAndExpectedType.kt
was working (inferred to String?) just because the branches
were analyzed independently with `String?` expected type.
This change became necessary after the previous commit when we united
inference subsystems for if/when branches (see motivation there).
NB: For K1, the behavior is left the same, but the code
was refactored a bit.
^KT-55691 Fixed
^KT-56448 Fixed
and assert that symbol is not a substitution/intersection override
in the `compute` method otherwise.
Because `fakeOverrideSubstitution` should be calculated for all real
implicit types, no call to this method should actually happen.
Otherwise, it can be problematic to create a session
which would contain the full designation path:
`provider.getFirCallableContainerFile(symbol)`
returns `firFile` of a super class which might be from module `a`,
when declaration and its outer classes are from module `b`.
^KTIJ-24105
Nikolay Lunyak