Using "JVM_1_8" always resulted in incorrect mapping of Kotlin
annotation targets to Java element types.
The change in AbstractKotlinRenderLogTest is needed because while
CliTraceHolder.module is technically a descriptor leak, it was never
detected by this test accidentally, because of the depth cutoff equal to
10, which started to not be enough after the minor refactoring of
replacing `Delegates.notNull` with `lateinit`.
Do not report same set of diagnostics for variable call if actual
error was happened with a function candidate. Here the candidate is
invoke function on DeepRecursiveFunction
^KT-40991 Fixed
^KT-41491 Fixed
^KT-40926 In Progress
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
Do not generate operations as lambdas; instead use `when` over
strings/enums, which is generated to tableswitch in the bytecode.
This reduces the proguarded compiler jar size by ~0.57%.
#KT-23565 Fixed
It leads to leak such type to the back-end. Calls within a builder call should be updated without marking CR and lambdas with DONT_CARE type.
^KT-43845 Fixed
^KT-43956 Fixed
^KT-42622 Fixed
Report a separate error when class files compiled with FIR are in
dependencies, in addition to the one for class files compiled with FE
1.0 + JVM IR.
#KT-43592
Introduce an enum DeserializedContainerAbiStability with two values.
This is needed in order to support another reason for ABI instability in
a subsequent commit, namely "unstable because compiled by FIR".
#KT-43592
During creation and initialization of module descriptor for sdk
in IdeaResolverForProject.BuiltInsCache.getOrCreateIfNeeded
AbstractResolverForProject asks for sdk dependency for module
descriptor for this sdk, so sometimes this module descriptor was
created twice
#KT-42001 Fixed
EA-211562
Those descriptors may be empty in case user made a mistake and tried to
delegate implementation of abstract class instead of interface (and
we don't add functions from abstract class to overriden descriptors
of fake overrides in case of delegation by)
#KT-40510 Fixed
All of new classes lays in lays in :compiler:tests-common-new module
which includes classes for FE 1.0 and FIR diagnostics tests and
JVM black boxtests
Alexander Udalov