Otherwise when the init block is followed by other constructor statements we can get a gap in a BasicBlock's child sequence due to the child init block never getting created at all.
We now get e.g.
[2022-03-09 13:59:04 K] [ERROR] Diagnostic(com.github.codeql.KotlinUsesExtractor.useSimpleType(KotlinUsesExtractor.kt:505)): Type alias ignored for <root>.Test<kotlin.String>{ <root>.Alias1<kotlin.String> }
...while extracting a function at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:7:1:7:41
...while extracting a function if real at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:7:1:7:41
...while extracting a declaration at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:7:1:7:41
...while extracting a file at file:///home/ian/code/dev/ql/java/ql/test/kotlin/library-tests/type_aliases/aliases_with_type_parameters.kt:1:1:8:0
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.
