Commit Graph

24 Commits

Author SHA1 Message Date
pyos 4fc1bd9ec5 Support inlining functions with KT-28064 style objects
Namely, anonymous objects defined in lambdas that have all captured
variables as loose fields instead of a single reference to the parent.

The question is, when a lambda inside an inline function defines an
anonymous object, and that object is not regenerated during codegen for
the inline function itself, but then has to be regenerated at call site
anyway, do we use an outer `this` or loose capture fields? For example,
before KT-28064:

    inline fun f1(g: () -> Unit) = object { g() }
    // -> f1$1 { $g: () -> Unit }
    inline fun f2(g: () -> Unit) = f1 { object { g() } }
    // -> f2$$inlined$f1$1 { $g: () -> Unit }
    //    f2$$inlined$f1$1$lambda$1 { this$0: f2$$inlined$f1$1 }
    inline fun f3(g: () -> Unit) = f2 { object { g() } }
    // -> f3$$inlined$f2$1 { $g: () -> Unit }
    //    f3$$inlined$f2$1$1 { this$0: f3$$inlined$f2$1 }
    //    f3$$inlined$f2$1$1$lambda$1 { this$0: f3$$inlined$f2$1$1 }

After KT-28064:

    inline fun f2(g: () -> Unit) = f1 { object { g() } }
    // -> f2$$inlined$f1$1 { $g: () -> Unit }
    //    f2$1$1 { $g: () -> Unit }
    inline fun f3(g: () -> Unit) = f2 { object { g() } }
    // -> f3$$inlined$f2$1 { $g: () -> Unit }
    //    f3$$inlined$f2$2 { ??? }
    //    f3$1$1 { $g: () -> Unit }

Should `???` be `this$0: f3$$inlined$f2$1` or `$g: () -> Unit`? This
commit chooses the latter for KT-28064 bytecode and keeps `this$0` when
inlining the old bytecode.
2019-11-06 13:11:44 +01:00
Georgy Bronnikov 7ede26e8f4 IrCompileKotlinAgainstInlineKotlin tests 2019-09-06 09:19:57 +03:00
Steven Schäfer 27a850be92 Fix genValueAndPut in IrInlineCodegen 2019-06-13 12:25:06 +02:00
Steven Schäfer 917ef250cf Add and (un)mute inline class tests 2019-06-13 12:25:06 +02:00
pyos 90f11211d3 JVM_IR: wrap performInline in enterIntoInlining/exitFromInliningOf 2019-05-06 16:23:28 +02:00
Roman Artemev 1338d6d66f Update tests 2018-10-19 14:07:20 +03:00
Roman Artemev 8a871b3f0c Update tests 2018-08-31 15:34:18 +03:00
Mikhael Bogdanov cb31962b38 Generate old style lambda classes in jvm ir backend 2018-08-13 15:10:20 +03:00
Mikhael Bogdanov a7d706f693 Unmute jvm ir-tests 2018-08-09 16:30:32 +03:00
Mikhael Bogdanov 357359b1dd Unmute ir-tests after CR support 2018-08-09 14:22:50 +03:00
Mikhael Bogdanov e149cbe852 Mute failed jvm ir tests 2018-06-28 12:26:41 +02:00
Anton Bannykh 3808d77bf4 JS IR: inliner 2018-06-18 13:15:19 +03:00
Anton Bannykh 96355e2732 JS IR: mute codegen box tests automatically 2018-06-09 19:15:38 +03:00
Anton Bannykh 68b35aa0ac JS inliner: Don't treat 'bar' as unused in the presence of 'bar.call' expressions 2016-11-18 20:55:07 +03:00
Alexander Udalov cc84aabdcf Migrate boxInline tests to new multi-file framework 2016-02-27 15:40:05 +03:00
Denis Zharkov 505dc61611 Treat extension receiver as noinline parameter
#KT-9574 Fixed
2016-01-29 14:36:53 +03:00
Denis Zharkov 098f5462eb Drop inlineOptions and fix forgotten usages 2015-09-23 12:18:12 +03:00
Denis Zharkov 9adde77c47 Replace inlineOption(ONLY_LOCAL_RETURN) with crossinline in testData 2015-09-18 10:14:33 +03:00
Michael Bogdanov 7025a4f933 Test framewrk update: check lambda inlining 2015-04-13 16:11:21 +03:00
Michael Bogdanov 67c2f7105b Fix for KT-6863: Internal compiler error folding functions
#KT-6863 Fixed
2015-04-10 08:59:27 +03:00
Stanislav Erokhin 3de0dff575 Migrate testdata to new lambda syntax 2015-04-07 13:08:53 +03:00
Michael Bogdanov ce71c5abde Test update for new ONLY_LOCAL_RETURN diagnostic 2014-07-07 10:51:46 +04:00
Mikhael Bogdanov 02c6bdeaa3 Inline test data structure changed 2014-07-07 10:51:46 +04:00
Mikhael Bogdanov 4f5b20a8db Test framework for inline 2014-03-03 15:43:35 +04:00