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
Test data for the wrongMetadataVersion test has changed because now not
only the .class files have the "future" version, but also the
.kotlin_module file, which prevents the current compiler from being able
to read what parts does a package in the library consist of. This is
related to the TODO in ModuleMapping.kt:89
Use the version requierement table of the outer DescriptorSerializer
instance when serializing metadata for a class. Pass parent serializer
to DescriptorSerializer.create to make sure the correct table is used.
Serialize nested classes before the outer class in JS and common code,
to make sure requirements are not lost. Also, split
VersionRequirementTest to JVM and JS
#KT-25120 In Progress
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
Caused by 4266e50be8 and 8ccbbf71ec. Previously it worked because we
used hardcoded signatures of equals/hashCode/toString and always looked
them up in java.lang.Object
#KT-25404 Fixed
Dmitry Petrov