[swift-dev] Help needed: Removing inout shadow copy from SILGen

[Daniel Duan]

I’ll add an assert and get rid of the conditional then. Thank you Adrian and Joe, for the great feedbacks!

- Daniel

> On Jun 9, 2016, at 10:09 AM, Adrian Prantl <aprantl at apple.com> wrote:
> 
>> 
>> On Jun 9, 2016, at 10:05 AM, Joe Groff <jgroff at apple.com> wrote:
>> 
>>> 
>>> On Jun 9, 2016, at 10:01 AM, Adrian Prantl <aprantl at apple.com> wrote:
>>> 
>>> On Jun 9, 2016, at 9:55 AM, Joe Groff <jgroff at apple.com> wrote:
>>>> 
>>>> 
>>>>> On Jun 8, 2016, at 7:38 PM, Daniel Duan via swift-dev <swift-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160609/e38196b1/attachment.html>