The main motivation for this change is that
java.lang.annotation.Repeatable has a parameter for the container
annotation, which is lost during conversion to
kotlin.annotation.Repeatable. To support j.l.a.Repeatable in backend
properly, it's absolutely necessary to be able to load the container
annotation for any repeatable annotation class, so the original
j.l.a.Repeatable needs to be stored in the descriptor and accessible
from the backend.
Instead of mapping j.l.a.Repeatable -> k.a.Repeatable, add a frontend
service PlatformAnnotationFeaturesSupport that will determine if an
annotation is repeatable "according to the platform rules", which for
JVM means that it's annotated with j.l.a.Repeatable.
Some effects of this change include:
- Usages of j.l.a.Repeatable are no longer reported as "deprecated", the
corresponding test is deleted
- Usages of repeatable annotations declared in Java with non-SOURCE
retention with LV 1.5 and earlier will now result in a slightly
different error (REPEATED_ANNOTATION instead of
NON_SOURCE_REPEATED_ANNOTATION)
#KT-12794
Seperate checker for platforms that do not support this language feature yet
Synthetic implementations of annotations are generated on-demand with proper
equals, hashCode, and annotationType methods
#KT-47699 Fixed
ObjectOutputStream.writeUTF(String) has an unsigned short limit on
String length. On Projects with deep nested modules subplugin
options could produce String over this limit.
^KT-45202 Fixed
On Windows, the absolute file for the root of the drive is `"C:\"`,
which differs from the absolute file for any other directory, which
doesn't end with `\`. This resulted in incorrect trimming of the first
character of the path name in `descendantRelativeTo`.
Also, do not use canonicalPath because there is no point in expanding
symbolic links here.
#KT-40979 Fixed
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
Forbid mixing suspend and non-suspend functional supertypes.
Since JVM BE generates suspend functional types as non-suspend ones
with SuspendFunction marker interface, there is not way to distinguish
non-suspend functional type from suspend one if they are mixed.
#KT-18707 Fixed
Dmitriy Dolovov