> On May 12, 2017, at 2:34 PM, Will Stanton <willstant...@yahoo.com> wrote: > > 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
Yes, the pass was disabled because it was causing miscompiles like this. John. > > 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
