Complex enum entries (those with bodies) with missing overrides
are covered by an existing checker that checks all types of classes. But
simple enum entries (those without bodies) were not covered and require
a separate checker for missing overrides.
#KT-58637 Fixed
* Also, mention implementation details of EnumEntries to enable safe uses of a 'EnumEntries' as a set
* Fix testdata for opt-in marker in enum entries
^KT-58548 fixed
Merge-request: KT-MR-10037
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Enum entries can be used as types in Kotlin (even it's a compilation error)
To use the classifier as a type, we need to find if it's hidden or not.
The deprecations for classes are calculated on COMPILER_REQUIRED_ANNOTATION phase, and that's okay as it goes before the TYPES phase.
For enum entries, the deprecations are calculated on TYPES phase which goes on TYPES phase.
This is incorrect as we cannot jump from lower phase to upper phase
The hack ignores such deprecation search for enum entires.
Test: org.jetbrains.kotlin.analysis.low.level.api.fir.diagnostic.compiler.based.LLFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated.Tests.testEnumEntryAsType
^KT-57648
^KT-56543
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
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
For example, NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER
It became especially relevant after 0e84bf2053
that together with later commits bring a lot of unnecessary
NEW_INFERENCE_NO_INFORMATION_FOR_PARAMETER diagnostic
After this commit we:
- preserve Enum.entries synthetic property in tower even in case the bound feature is OFF
- report an error on Enum.entries call in specific checker if the feature is OFF
- give this synthetic property lower priority, no matter feature ON or OFF
#KT-55251 Fixed
Note that there is a questionable behavior that will be fixed later.
Right now it's not fully clear because for the same situation in Kotlin, the compiler reports warnings at declaration-site and it's not possible to do so for Java
^KT-53153
Roman Efremov