Property modification not taking effect


(Pushkar N Kulkarni) #1

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(… …))

after => transferReady(Foundation.URLSessionTask._TransferState(… …))

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(… …))

after => transferInProgress(Foundation.URLSessionTask._TransferState(… …))

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.

Pushkar N Kulkarni,

IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra


(John McCall) #2

That sounds like a serious bug; please file it in JIRA.

John.

···

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 <https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSURLSession/NSURLSessionTask.swift#L329>.

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.


(Pushkar N Kulkarni) #3

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

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(… …))

after => transferReady(Foundation.URLSessionTask._TransferState(… …))

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(… …))

after => transferInProgress(Foundation.URLSessionTask._TransferState(… …))

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.

John.

···

On May 9, 2017, at 3:07 PM, Pushkar N Kulkarni via swift-dev swift-dev@swift.org wrote:

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: John McCall
Sent by: rjmccall@apple.com
Date: 05/10/2017 04:19AM
Cc: swift-dev swift-dev@swift.org
Subject: Re: [swift-dev] Property modification not taking effect

That sounds like a serious bug; please file it in JIRA.

-----rjmccall@apple.com wrote: -----


(Pushkar N Kulkarni) #4

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!

Pushkar N Kulkarni,

IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra

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

···

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: John McCall
Sent by: rjmccall@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(… …))

after => transferReady(Foundation.URLSessionTask._TransferState(… …))

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(… …))

after => transferInProgress(Foundation.URLSessionTask._TransferState(… …))

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

To: John McCall rjmccall@apple.com
From: Pushkar N Kulkarni via swift-dev
Sent by: swift-dev-bounces@swift.org
Date: 05/10/2017 06:00PM
Cc: swift-dev swift-dev@swift.org
Subject: Re: [swift-dev] Property modification not taking effect

-----rjmccall@apple.com wrote: -----

-----swift-dev-bounces@swift.org wrote: -----


(John McCall) #5

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.

···

On May 10, 2017, at 11:06 AM, Pushkar N Kulkarni <pushkar.nk@in.ibm.com> wrote:

Pushkar N Kulkarni,
IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra

-----swift-dev-bounces@swift.org <mailto:-----swift-dev-bounces@swift.org> wrote: -----
To: John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>>
From: Pushkar N Kulkarni via swift-dev
Sent by: swift-dev-bounces@swift.org <mailto:swift-dev-bounces@swift.org>
Date: 05/10/2017 06:00PM
Cc: swift-dev <swift-dev@swift.org <mailto: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

-----rjmccall@apple.com <mailto:-----rjmccall@apple.com> wrote: -----
To: Pushkar N Kulkarni <pushkar.nk@in.ibm.com <mailto:pushkar.nk@in.ibm.com>>
From: John McCall
Sent by: rjmccall@apple.com <mailto:rjmccall@apple.com>
Date: 05/10/2017 04:19AM
Cc: swift-dev <swift-dev@swift.org <mailto: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 <mailto: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 <https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSURLSession/NSURLSessionTask.swift#L329>.

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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(Will Stanton) #6

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.nk@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-bounces@swift.org wrote: -----
To: John McCall <rjmccall@apple.com>
From: Pushkar N Kulkarni via swift-dev
Sent by: swift-dev-bounces@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

-----rjmccall@apple.com wrote: -----
To: Pushkar N Kulkarni <pushkar.nk@in.ibm.com>
From: John McCall
Sent by: rjmccall@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.


(John McCall) #7

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.

···

On May 12, 2017, at 2:34 PM, Will Stanton <willstanton1@yahoo.com> wrote:

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.nk@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-bounces@swift.org wrote: -----
To: John McCall <rjmccall@apple.com>
From: Pushkar N Kulkarni via swift-dev
Sent by: swift-dev-bounces@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

-----rjmccall@apple.com wrote: -----
To: Pushkar N Kulkarni <pushkar.nk@in.ibm.com>
From: John McCall
Sent by: rjmccall@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.


(Pushkar N Kulkarni) #8

Will/John,

Pushkar N Kulkarni,

IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra

I can submit a PR to add this test if you think there’s value in it. Thanks.

···

To: John McCall rjmccall@apple.com
From: Will Stanton willstanton1@yahoo.com
Date: 05/13/2017 12:04AM
Cc: Pushkar N Kulkarni pushkar.nk@in.ibm.com, swift-dev swift-dev@swift.org
Subject: Re: [swift-dev] Property modification not taking effect

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.nk@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-bounces@swift.org wrote: -----
To: John McCall rjmccall@apple.com
From: Pushkar N Kulkarni via swift-dev
Sent by: swift-dev-bounces@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

-----rjmccall@apple.com wrote: -----
To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: John McCall
Sent by: rjmccall@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(… …))
after => transferReady(Foundation.URLSessionTask._TransferState(… …))

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(… …))
after => transferInProgress(Foundation.URLSessionTask._TransferState(… …))

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.

-----Will Stanton willstanton1@yahoo.com wrote: -----