I opt to identify any syntactic initializer. These are broader in scope than Java's member initializers, which are necessarily context-free, whereas in Kotlin the primary constructor's parameters can be referred to.
Pros:
* <obinit> no longer emitted: one less function per class
* Parameters to the primary constructor, if any, are no longer referred to out of scope
* Simple primary constructor `val` and `var` declarations work as expected
Cons:
* If there are multiple secondary constructors, no primary constructor and long init blocks, there could be considerable duplicate extraction of those init blocks. Hopefully this case is very rare.
These are extracted as "throw new kotlin.NoWhenBranchFoundException();", which is the Java lowering of the intrinsic.
In the process, amend the control-flow graph to let when branches propagate `throw`s outwards, and similarly statement expressions.
* Extract varargs as if they are ordinary positional arguments
* Adapt the QL that distinguishes varargs from ordinary arguments to account for Kotlin's varargs which can occur in the middle of the arg list
* Add a test checking dataflow through varargs which doesn't work yet due to array-get and array-set not being extracted as IndexExprs
* Extract the special case arrayOf(*x) as a clone call, which is (equivalent to) the Java lowering of that operation
The warning in the extractor is inaccurate due to references to enclosing types' type parameters. A consistency query can check that the type parameter is indeed in scope exploiting broader knowledge of the enclosing types.
Type arguments: yes outer classes can have arguments; they are appended after the full name.
String concatenation: this used to be worse before this unquoted version of the function existed; I think that's what the comment was complaining about.
Turns out the two use cases the TODO worried about are already taken care of: `Unit` is replaced with `void` only in contexts where primitives can be used, and `List` and similar only have incompatible extension methods, which are declared by `CollectionsKt` not `List`. This is likely deliberate to enable the Kotlin <-> Java substitution to be implemented simply by kotlinc.
