I am a bit curious about Pushkar’s test case; perhaps it should be added as a 
test?

The SIL emitted then vs ~today looked very similar, so I was thinking the issue 
might be in IRGen.
Scanning there, looks like this cured the problem:
@shajrawi https://github.com/apple/swift/pull/9452 Disable large types irgen 
pass

The property change happens when the pass is disabled, but before 
f9861fe6fcd9d797653f62a0b0c4142e719eecf1, the change does not happen:
before => ready(test.TState(drain: test.Drain.foo("wow")))
after => ready(test.TState(drain: test.Drain.foo("wow")))

The `newValue` access in willSet apparently ‘alters’ it to the old value.
https://bugs.swift.org/browse/SR-4852

Regards,
Will Stanton

> On May 10, 2017, at 1:08 PM, John McCall via swift-dev <swift-dev@swift.org> 
> wrote:
> 
>> On May 10, 2017, at 11:06 AM, Pushkar N Kulkarni <pushkar...@in.ibm.com> 
>> wrote:
>> The issue is seen with the 05-09 dev snapshot. However after updating the 
>> repos today, I no longer see it! 
>> 
>> Looks like one of yesterday's commits (which did not go into 05-09)  fixed 
>> it. I am closing the JIRA report. Thanks!
> 
> Okay, glad we managed to fix it; thanks.
> 
> John.
> 
>> 
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
>> 
>> -----swift-dev-boun...@swift.org wrote: -----
>> To: John McCall <rjmcc...@apple.com>
>> From: Pushkar N Kulkarni via swift-dev 
>> Sent by: swift-dev-boun...@swift.org
>> Date: 05/10/2017 06:00PM
>> Cc: swift-dev <swift-dev@swift.org>
>> Subject: Re: [swift-dev] Property modification not taking effect
>> 
>> Thanks John. This is the JIRA bug report: 
>> https://bugs.swift.org/browse/SR-4852
>> 
>> I was able to write a small test case that shows the regression:
>> 
>> enum State {
>>     case ready(TState)
>>     case inProgress(TState)
>> 
>>     var isPaused: Bool {
>>         switch self {
>>         case .ready: return false
>>         case .inProgress: return false
>>         }
>>     }
>> }
>> 
>> enum Drain {
>>     case foo(String)
>>     case bar(Int, String)
>> }
>> 
>> struct TState {
>>     let drain: Drain
>> }
>> 
>> class Task {
>>     var state = State.ready(TState(drain: .foo("wow"))) { 
>>         willSet {
>>             if newValue.isPaused { }
>>         }
>>     }
>> 
>>     func resume() {
>>         if case .ready(let tState) = state {
>>             print("before => \(state)")
>>             state = .inProgress(tState) //doesn't take effect
>>             print("after => \(state)")
>>         }
>>     }
>> }    
>> 
>> //main
>> Task().resume()
>> 
>> Output with the latest master:
>> before => ready(Test.TState(drain: Test.Drain.foo("wow")))
>> after => ready(Test.TState(drain: Test.Drain.foo("wow")))
>> 
>> 
>> Expected output (and with the 04-24 snapshot as well):
>> before => ready(Test.TState(drain: Test.Drain.foo("wow")))
>> after => inProgress(Test.TState(drain: Test.Drain.foo("wow")))
>> 
>> 
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
>> 
>> -----rjmcc...@apple.com wrote: -----
>> To: Pushkar N Kulkarni <pushkar...@in.ibm.com>
>> From: John McCall 
>> Sent by: rjmcc...@apple.com
>> Date: 05/10/2017 04:19AM
>> Cc: swift-dev <swift-dev@swift.org>
>> Subject: Re: [swift-dev] Property modification not taking effect
>> 
>>> On May 9, 2017, at 3:07 PM, Pushkar N Kulkarni via swift-dev 
>>> <swift-dev@swift.org> wrote:
>>> In the process of debugging a bunch of consistent failures in 
>>> TestFoundation/TestNSURLSession, I came across a weird problem symptom in 
>>> this line of code.
>>> 
>>> internalState = .transferInProgress(transferState)
>>> 
>>> I had a suspicion that the above modification is not taking effect, since, 
>>> only based on this change the didSet observer for the `internalState` 
>>> property triggers data transfers using libcurl. So, I simply printed the 
>>> property before and after the assignment. 
>>> 
>>> print("before => \(internalState)")
>>> internalState = .transferInProgress(transferState)
>>> print("after => \(internalState)")
>>> 
>>> Surprisingly, I don't see any change in the property value:
>>> before => transferReady(Foundation.URLSessionTask._TransferState(... 
>>> <redacted> ...))
>>> after  => transferReady(Foundation.URLSessionTask._TransferState(... 
>>> <redacted> ...))
>>> 
>>> When I switched back to the "swift-DEVELOPMENT-SNAPSHOT-2017-04-24-a" tag 
>>> on all the repos (except swift-corelibs-foundation), I do not see this 
>>> problem. I see:
>>> before => transferReady(Foundation.URLSessionTask._TransferState(... 
>>> <redacted> ...))
>>> after  => transferInProgress(Foundation.URLSessionTask._TransferState(... 
>>> <redacted> ...))
>>> 
>>> To put it in simple terms, the modification doesn't seem to be taking 
>>> effect with the current HEAD. 
>>> 
>>> I haven't been able to isolate this problem in an independent test case. 
>>> However, anybody who wants to reproduce it can simply run TestFoundation 
>>> after enabling the URLSession tests (which have been disabled for now) in 
>>> TestFoundation/main.swift. 
>>> 
>>> I did compare the `-emit-ir` outputs from the passing and failing levels. 
>>> There seems to be a clear difference in the way we store the new value of 
>>> this property. But given my limited exposure to debugging Swift compiler 
>>> issues, I wasn't able to progress further.  
>>>  
>>> Can someone help us here please? Thanks. 
>> 
>> That sounds like a serious bug; please file it in JIRA.
>> 
>> John.


_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to