- don't box/unbox when value is known to be an inline class
- add unbox state when coroutine resumed
- correctly handle suspension in case of inline class
- add tests
- fix BE
- fix Serializer
- implement builder
- make Ir a bit more type-correct
- support developer mode (lowering [dynamic]implicit cast meterialized as general cast)
- fix autoboxing lowering
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.
Dmitriy Novozhilov