The ir type checker cannot deal with types with an incorrect number of arguments.
On the other hand, the JVM IR backend sometimes produces "raw types" - types with
generic parameters but without arguments. This commit removes such raw types as
much as possible, by replacing calls to "typeWith()" with calls to "defaultType"
for classes without type parametes (defaultType doesn't allocate, unlike typeWith)
and with calls to "starProjectedType" for classes with type parameters.
Code in inline lambdas can call multifile part members. These calls are
replaced in GenerateMultifileFacades with the call to the facade member.
Previously this didn't happen though because the lambda body was removed
before the GenerateMultifileFacades phase, which led to
IllegalAccessError in the -Xmultifile-parts-inherit mode (because the
part class is package private in another package).
The problem was that we tried to generate an `$annotations` method for a
property declared in an annotation class. That method is final and has a
body, which is not allowed in annotation classes. Now we're generating
this method in the separate `$DefaultImpls` class as for properties in
interfaces.
Note that the added test still doesn't find any annotations because the
proper support is needed in reflection (KT-22463). Currently it only
checks that no VerifyError happens.
In addition to fixing getContainingDeclaration, change origin of
multifile facades to FILE_CLASS since the corresponding class descriptor
should also be skipped when computing containing declaration. This fixes
the problem with internal function calls in -Xmultifile-parts-inherit
mode (previously we incorrectly mangled the function name in
MethodSignatureMapper), and also fixes coroutine intrinsic calls when
compiling kotlin-stdlib with JVM IR. In the latter case, all intrinsics
(such as isBuiltInSuspendCoroutineUninterceptedOrReturn) are present in
sources, and were previously not detected as intrinsics by the code in
`generateInlineIntrinsic` because the FQ name didn't match: it had an
additional component for the file class name.
May happen when a function in an `expect` class is aliased through an
`actual typealias`; the matching declaration is filtered out in
`ExpectedActualResolver.findActualForExpected` as it has no source.
Profiling has shown, that supertype hierarchy scan for all calls has considerable
performance cost. However, missing supertypes may be calculated only once per
descriptor which would help avoiding multiple supertype hierarchy scans for
resolved calls from the same class. New memoizer is injected into call completers
and checker contexts and then used for retrieving missing super classifiers.
#KT-19234 Fixed
Default mock JDK from IDEA 193, "wins" mock JDK from kotlin in some tests.
In script configuration test this breaks resolution of java declarations from script environment.
Overriding getTestProjectJdk replaces default test project JDK with kotlin mock JDK.
Configuration in AbstractMultiFileHighlightingTest was updated similarly to fix test failures.
Call checker and declaration checker are used in order to preserve backward compatibility.
Attempt to use classifier usage checker was not good enouth,
since not all errors found with it would actually be reported before.
For example types and constructor calls don't cause supertypes to resolve,
so missing supertypes would not lead to errors in case they are the only use of class name.
Updated tests failing due to missing Java dependencies in superclasses.
Adjustments for missing superclasses checker.
Some hierarchies in mock JDK are incomplete.
Absence of its .class file causes some tests to fail without an actual error.
To mitigate this problem, top-level classes and interfaces can only inherit from entries that belong to mock JDK.
Absent superclasses are replaced with java.lang.Object.
This only affects runtime jar of mock JDK.
Technically a backwards compatibility problem, as the new backend
*consistently* renamed `f$default` on `f` with `@JvmName("g")` to
`g` instead of `g$default`, so it all worked out. However, this
breaks when encountering libraries compiled with the non-IR backend.
Substituting inferred type parameters with single substitutor leads
to incorrect behaviour in cases, when class' type parameters are used in constructor.
As a side effect of two-step substitution, intermediate descriptor is created,
which prevents incorrect substitution. To preserve this side effect, single
resulting substitutor was split into two substitutors: one for substituting fresh
variables and another for substituting inferred variables and known parameters.
^KT-32415 Fixed
Known type parameters appear after inheriting from class with type
parameters. Their substitution matters for inner class constructor,
because without substitution it's parameters will be type checked
against incorrect (original) parameter descriptor with unsubstituted
type parameters.
Skip creation of composite substitutor, if old substitutor is empty.
New substitutors return null in case they don't substitute a type,
but old type substitutors have explicit isEmpty method. Composite
substitutor with empty old substitutor leads to creation
of incorrect descriptor copies.
`kotlinx-metadata-klib` is an extension of `kotlinx-metadata` that can be used to read and write metadata that is stored inside KLIBs.
Note: current version is in its early days and in active development. Almost nothing is stable or properly tested.
Dmitriy Novozhilov