> On Jun 9, 2016, at 10:05 AM, Joe Groff <jgr...@apple.com> wrote: > >> >> On Jun 9, 2016, at 10:01 AM, Adrian Prantl <apra...@apple.com> wrote: >> >> On Jun 9, 2016, at 9:55 AM, Joe Groff <jgr...@apple.com> wrote: >>> >>> >>>> On Jun 8, 2016, at 7:38 PM, Daniel Duan via swift-dev >>>> <swift-dev@swift.org> wrote: >>>> >>>> Hi all, >>>> >>>> I'm resuming work on removing the SILGen for the inout shadow copy. Making >>>> this change involes quite a bit of tests updates. I'd love some one to >>>> review >>>> this commit in SILGenProlog.cpp before I dive back into the deep end: >>>> >>>> https://github.com/dduan/swift/commit/e56d73c065bec7bdde7c0ffee42b808d1bb52d74 >>>> >>>> (It's +5, -12, a small patch). >>>> >>>> Is this on the right track? >>> >>> The variable binding looks great. We might need to coordinate with the >>> debugger to ensure we still emit debug info the way lldb expects it; cc'ing >>> Adrian and Enrico. >>> >>> -Joe >> >> The diff looks generally reasonable to me. You will probably have to update >> a bunch of debug info testcases along with this change. >> >> You can run the LLDB test suite with by running >> $ build-script -r -l -t -- --skip-test-cmark --skip-test-swift >> --lldb-test-with-curses --lldb-use-system-debugserver >> >> Since I missed the original discussion, I’m curious about the context >> though: under what circumstances is an inout argument be passed by value and >> can it ever be a let binding? > > An inout can never be a 'let' binding.
In that case, the we might want to assert that !vd->isLet() in the patch. > It's always passed by-reference, but previously, we would inject a shadow > copy with writeback on the callee side to allow captures to reference the > inout without extending the original argument's lifetime. We no longer allow > this, so inouts are always simply passed by reference now. And does this imply that it is always an address? If so, we might want to assert this and get rid of the else branch handling the value. thanks, adrian _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
