Before this commit we relied on a fact that exotic types aren't
possible at serialization stage. However, in non-ABI mode we can get
even a private function (e.g. top-level private), so we have to perform
this approximation.
Bytecode generated by JVM IR ensures that on multiline expressions,
every call is stepped over, which seems better than in the old backend.
Also remove kt34905.kt since it duplicates this test case.
The only difference seems to be that step into IImpl.fooOverride is
actually supported in JVM_IR. Also fix slightly incorrect line numbers
in the comments.
The difference is that JVM_IR generates line numbers for the
constructor field initialization.
In this case:
```
29: class B {
30: // comment
31: val bPropVal: Int,
32: // comment
33: var bProbVar: Int
34: ) {
```
the line numbers for the field initializations are 31 and 33 where
in the current backend the whole constructor has line number 29.
JVM IR backend doesn't support old coroutines, so we disable it via
-Xno-use-ir, just as for the main source set. This option has no effect
for the current master builds, but will be necessary once JVM IR is
enabled project-wide.
This dependency was unused. It allows to avoid waiting for compiling
kotlin-reflect (which includes descriptors, deserialization, etc.)
before compiling FIR modules and thus improves total build time.
When a suspend lambda does not capture crossinline lambda, it is
generated with as state-machine, since it does not inline anything.
However, when regenerating, the inliner used to remove all DebugMetadata
annotations to avoid duplication. This lead to missing annotation if
the lambda is regenerated, but state-machine is not regenerated.
This change fixes the blind spot by readding the annotation after
regeneration.
#KT-41789 Fixed
For large projects, incremental comilation mapping information may be quite
large. With configuration caching enabled, each task gets its own copy of that
state, and for a project with 1400 subprojects, this resulted in 3.6GB of additional
state stored (once task graph is cached).
This change introduces IncrementalModuleInfoProvider which allows build service
to be used if configuration caching is enabled, and it falls back to static
constant otherwise.
Ilmir Usmanov