This commit add feature for disabling searching for data class ComponentN method and destruction declarations that could encrease usages search.
See KT-23278
New behavior was introduced in ab506c1579 which breaks compilation on IDE module (see test example) for new inference.
Now we temporarily disable this optimisation. This is temporarily restriction which will be fixed once we'll have the same rules for lambdas completion
#KT-34889 Open
Resolves the interaction of @JvmOverloads annotations and
parameterless main methods.
In the following code, both mechanisms generate methods that
ultimately produce the signature `public static void main(String[] args)`
of which there can be only one (true in general of any signature).
```
fun main() { }
@JvmOverloads
fun main(Array<String> args, x: Int = 42) { }
```
This PR simply shuffles the lowerings around, letting parameterless
main methods detect the presence of the default overload produced by
the annotation.
Additionally, this PR improves the testing of parameterless main
methods by actual bytecode patterns, and not simple check for
successful compilation (as @sfs and I discovered, there are issues in
flagging an error on duplicate signatures on the IR backend).
Case of incorrect call expression as the receiver of dot-qualified expression
was not handled properly.
Now the following order is used:
- If parent is a call expression or if this call is a receiver of parent
dot-qualified expression, parent must get last lambda as a new receiver;
- Otherwise, if parent is a dot-qualified expression, this call is in selector position.
Then grandparent is checked for being call or dot-qualified expression. If so, trailing
lambda must become grandparent's new receiver. If not, trailing nodes become standalone
epressions after parent.
- Otherwise, incorrect call expression is a standalone expression, so trailing nodes
may be lifted and put after it.
Quickfix wasn't aware of cases, when expression to be fixed
is a part of parent call expression or dot-qualified expression.
Incorrect position for extracting trailing lambdas led to broken
formatting.
#KT-34694 Fixed
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.
Dmitry Savvinov