Otherwise this code behaves incorrectly on getter-only properties: it
returns a meaningless field signature whereas the property has no field.
It's hard to come up with an example of when this could matter in
compiler code, but it's very noticeable in kotlinx-metadata-jvm
#KT-26188 Fixed
This has no effect on the correct code currently, but will help in
debugging when changing the serialized metadata for properties.
For example, if after some change an empty propertySignature extension
is written for Property (it's possible for PropertyDescriptor without
getter or setter and without backing field), we now won't try to read a
missing getter message when loading annotations on property getter. In
protobuf, reading a missing message will result not in an exception, but
in a "default" message being returned, which makes no sense in our case
because it would simply be read as a getter signature with both "name"
and "desc" equal to 0 (i.e. the first entry in the string table)
This is still not 100% foolproof because one may place such a
requirement manually on a suspend function (with `@RequireKotlin`, for
example), which will trick the compiler into thinking that this is a new
suspend function, even if it was compiled with old coroutines. But it's
still better than only checking the version number
Replace ones from org.jetbrains.kotlin package with new annotations from kotlin.annotations.jvm.
No need to copy them to compile kotlin-reflect anymore.
Then simplify reflect project more: no sources — no need to pack its direct output.
The exception was incorrectly introduced in 0f0602230a. We should not
fail when `names` is null, only when there's no element at the
corresponding index. On Java 6, `names` is always null. On Java 8,
`names` is never null (it's an empty list if the class was compiled
without "-parameters")
PSI-based implementation (accessible via
`-Xuse-old-class-files-reading`) loads parameter names from the
"MethodParameters" attribute if it's present, so our own implementation
should as well.
This metadata doesn't seem supported in the java.lang.model.element API
though, so SymbolBasedValueParameter (which is used in `-Xuse-javac`)
will continue to have incorrect behavior for now
#KT-25193 Fixed
Move parts of the logic to the only places where they're needed:
checking for public/final/val is only needed in
JvmFieldApplicabilityChecker, checking the proto flag is only needed in
reflection, checking the JvmField annotation presence is only needed in
backend
Previously, packages `java.lang` and `kotlin.jvm` were imported on JVM
by default on the same rights, causing problems when the same classifier
existed both in `java.lang` and `kotlin.jvm`. Since the only known case
of such conflict were type aliases to JVM classes, the corresponding
classes (expansions of those type aliases) were manually excluded from
default imports. This made the code in DefaultImportProvider complicated
and resulted in multiple problems, regarding both correctness and
performance (see 82364ad3e5, a9f2f5c7d0, dd3dbda719).
This change adds a new concept, a "low priority import", and treats
`java.lang` as such. Since these imports are now separated from the rest
of default imports in LazyImportScope via secondaryClassImportResolver,
conflicts between classifiers are handled naturally: the one from
`kotlin.jvm` always wins (unless the one from `java.lang` is imported
explicitly, of course). This approach is simpler, safer and does not
require any memory to cache anything.
Skip ResolveToJava.kt test for javac-based resolve; it now fails because
of a weird issue which I didn't have time to investigate (this is OK
because it's a corner case of an experimental functionality)
The implementation is a bit obscure because this worked on JS since
Kotlin 1.0 and we should not break that; however, on JVM, a diagnostic
will be reported with old language/API version
#KT-25241 Fixed
Alexander Udalov