They are not `FirRegularClassSymbol`, but are
final. `FirClassSymbol` is enough, because
`toSymbol()` returns `FirClassifierSymbol`, and:
- type parameters are always expected to have
subtypes
- typealiases have been expanded in the
previous line
It was decided to forbid such comparisons,
as we know how `===` works. Also, added some more
test cases, just for comparison.
Reusing the proper `canHaveSubtypes()`
from `TypeUtils` prevents a breaking change
in:
- `comparingTripleWithPair.kt`
- `comparisonOfGenericInterfaceWithGenericClass.kt`
But it does lead to warnings
(instead of errors) in
`incompatibleEnumEntryClasses.kt`, which is an
unrelated mistake that will be fixed in the next
commit.
The refactoring in `canHaveSubtypes()` is purely
cosmetic - otherwise reading these conditions is hard
(and they don't fit my screen vertically).
^KT-62646
^KT-65541
^KT-57779
This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
When both sides of an equality expression are null or Nothing?, only the
right side is receiving implications within the data-flow. Make sure the
left side has implications add as well. This is important for boolean
conditions when implications from both sides need to be combined.
^KT-63535 Fixed
Terminating a CFG node because the result is Nothing should be reserved
for explicit Nothing type definitions, and not apply when smartcasting.
This allows boolean expressions to propagate implications correctly even
when the RHS is impossible or will never be executed.
^KT-47931 Fixed
This uses the same approach as
INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION where we use a visitor
to find a call to a symbol that contains the type variable in question.
#KT-56140 Fixed
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
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
Some of the changed tests may duplicate other existing diagnostics,
but that should not be reason not to report them at all.
There might be another job to be done to avoid diagnostic duplications
FE1.0 only reports SENSELESS_COMPARISON if one of the operand is `null`.
This change makes FIR reports also in case one of the operand has type
`Nothing?`.
In addition, fix handling of type alias in ConeTypeContext#isNullableType
Added checker for FirEqualityOperatorCall. It's surfaced as one of the
following diagnostics depending on the PSI structure and types under
comparison:
* INCOMPATIBLE_TYPES(_WARNING)
* EQUALITY_NOT_APPLICABLE(_WARNING)
* INCOMPATIBLE_ENUM_COMPARISON_ERROR
Comparing with FE1.0, the current implementation is more conservative
and only highlights error if the types are known to follow certain
contracts with `equals` method. Otherwise, the checker reports warnings
instead.
However, the current checker is more strict in the following situations:
1. it now rejects incompatible enum types like `Enum<E1>` and
`Enum<E2>`, which was previously accepted
2. it now rejects incompatible class types like `Class<String>` and
`Class<Int>`, which was previously accepted
3. the check now takes smart cast into consideration, so
`if (x is String) x == 3` is now rejected
Previously unsafe call is reported as part of InapplicableWrongReceiver.
This makes it difficult for the downstream checkers to report different
diagnostics.
To do so, inside the root cause of inapplicable candidate errors,
we will record expected/actual type of receiver, if any.
That will help identifying inapplicable calls on nullable receiver.
This commit includes a lot of minor changes in testdata: new infrastructure
requires that each test file in one testdata file in one module must
have unique name, but a lot of existing spec tests didn't satisfy
this requirement
Nikolay Lunyak