Fix built-ins for JVM platform and make them consistent
with module's dependency on standard library. Changes
don't affect non-JVM platforms.
Previously all built-ins in IDE were loaded from classloader
and were based on the same pre-serialized .kotlin_builtins files.
This approach is generally not correct as built-in declarations
differ for different platforms, but it had been working for a while
without immediately observalble effects (see KT-33233 for more info).
After changes in standard library JvmBuiltins started producing
false errors (see KT-39728).
To fix this, JVM built-ins in IDE now utilize the same technique as
applied in CLI: using dependency on standard library as a module
for built-ins instead of artificial module that considers only
.kotlin_builtins.
Change summary:
- Provide JvmBuiltins with kind FROM_DEPENDENCIES
for all modules with stdlib dependency in IDE
- Add JvmBuiltinsPackageFragmentProvider to JVM-ish module resolvers
(JVM and Composite with JVM platform) to support their use as
built-ins module
- Create KotlinBuiltInsMetadataIndex file index for tracking libraries
containing .kotlin_builtins to support JvmBuiltinsPackageFragmentProvider
- Create KotlinStdlibIndex file index for tracking kotlin-stdlib(-common),
which looks for "Kotlin-Runtime-Component" manifest attribute
- Add caching service to track LibraryInfo for kotlin-stdlib(-common)
- Put LibraryInfo for kotlin-stdlib(-common) alongside SDKs
due to the need to resolve that modules in BuiltInsCache
- Update BuiltInsCache to separate JvmBuiltins by module's dependency
on stdlib and JDK
- Make platform of KotlinSDK common instead of JVM
- Set built-ins module lazily in IDE
^KT-33233 Verification Pending
It doesn't matter because this built-ins instance will be used only to
get names of default imports, so nothing can be resolved to those
built-ins => no diagnostics will be reported
This commit adds relevant functions: hashCode, toString, equals
(if the class is not a data class)
And supertype j.l.Record
It only affects descriptor contents, i.e. works for FE
^KT-43677 In Progress
In order to hide synthetic property isEmpty from JDK 15, there was
added additional logic in 5cc12b49fc but
it also lead to the fact that now it's impossible to call synthetic
property `declaringClass` on `Enum` as it's in the same list as method
isEmpty(). Note that it's questionable behavior, probably we should
also hide `declaringClass` as well but for now we turn it back to
preserve compatibility
#KT-42467 Fixed
Pavel Kirpichenkov