Support this for single file facades as well as for multi-file classes,
similar to code in
MultifileClassCodegen.writeKotlinMultifileFacadeAnnotationIfNeeded.
Extend the test on this attribute to also cover multi-file classes.
so that the enclosing method of objects defined inside lambdas is the
one they are declared in.
Note that this does not fix *all* enclosingInfo tests because JVM_IR
currently follows the KT-28064 proposal, i.e. does not regenerate
objects defined inside lambdas under any circumstances. For example,
this causes test boxInline/enclosingInfo/inlineChain2.kt to fail because
the enclosing method of objects is _2Kt.box instead of (non-existent in
source code) `_2Kt$box$inlined$call$1.invoke` or whatever. What's more
important is that OUTERCLASS no longer points to a non-existent
`box$lambda-N` and therefore `.enclosingMethod` no longer throws.
This makes sense because this mode is the default in the production
compiler. Forgetting to enable it where necessary led to different
bizarre test failures, see for example changes around 3fee84b966 and
KT-34826
For example, a lambda `{ param -> captured }` of type `E.(T) -> U` will
be transformed by LocalDeclarationsLowering into a private static method
fun f$lambda-0($this: E, $captured: U, param: T) = $captured
The reason for such an ordering is that a lambda looks the same as a
local function, and local function can have default arguments, and those
arguments can reference captured variables; thus, captured variables
must come before actual declared arguments.
However, this is not the order that the inliner wants. Moreover, since
it was written to handle lambdas represented as `invoke` methods of
anonymous objects, it does not expect the actual callable method to have
any parameters corresponding to captured variables at all. This results
in it attempting to generate a temporary node with descriptor
(LE;LU;LT;LU;)LU;
while still using locals 1 and 2 as `param` and `$captured` respectively.
In the example above, this is not critical, as they both have reference
type and the lambda will eventually be pasted into a different node
anyway; however, if it happens that one of them is a primitive, or both
are primitives of different types, the bytecode will use incorrect
instructions, causing verification errors. The correct descriptor is
(LE;LT;LU;)LU;
Necessary to support importing file classes annotated @JvmPackageName,
since the actual package fragment they are a part of has the name from
the `package` declaration.
Alexander Udalov