Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-13114] switch statement over enum instance should release references in associated values on successful pattern match #55560

Open
tayloraswift opened this issue Jun 29, 2020 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@tayloraswift
Copy link
Contributor

Previous ID SR-13114
Radar rdar://problem/64953109
Original Reporter @Kelvin13
Type Bug
Environment

$ swift --version
Swift version 5.2-dev (LLVM 4cd92ac, Swift 79716ef)
Target: x86_64-unknown-linux-gnu

Additional Detail from JIRA
Votes 0
Component/s
Labels Bug
Assignee None
Priority Medium

md5: 8181bfb6c40eae032241ad95f2b96f51

is duplicated by:

  • SR-13113 assignment to enum instance should recursively deinitialize associated values

Issue Description:

Right now, it seems that `switch` statements appear to retain a strong reference to the associated values in the `enum` case for the duration of the `case` block's execution. However, the payloads are no longer needed after the pattern matching succeeds, so they should be released at the beginning of the `case` block, with locally bound associated values taking an additional retain as needed.

    // example
    e = .s(.init()) // +1 (total: 1)
    switch e // +1 (total: 2)
    {
    // +1 for var binding (total: +3)
    case .s(var s): 
    // -1 for return from pattern match (total: +2)
        s.foo() 
        e = .empty // -1 (total: +1)
        s.foo() // should be uniquely referenced
   
    default:
    // -1 for return from pattern match (total: +1)
        break
    }

this issue is probably related to: https://bugs.swift.org/browse/SR-13113

@rjmccall
Copy link
Member

@gottesmm, this is related to your work.

@CodaFi
Copy link
Member

CodaFi commented Jun 30, 2020

@swift-ci create

@swift-ci
Copy link
Collaborator

swift-ci commented Jul 3, 2020

Comment by Sighoya (JIRA)

John McCall wrote in SR-13112:

>I'm going to close this one; it's acceptable for `isKnownUniquelyReferenced` to change from `false` to `true` under optimization as a general matter. Whether `switch` should guarantee to not separately keep the switch value alive in unoptimized builds is better tracked as SE-13114.

Afaik, it is desireable that a program after optimization shares the same semantics as the program before.

Flipping true to false or vice versa doesn't belong to this kind of desire.

@rjmccall
Copy link
Member

rjmccall commented Jul 5, 2020

That is generally true, but `isKnownUniquelyReferenced` is an exception: it is testing something that is generally an implementation detail that the optimizer is permitted to affect (specifically by changing the result from `false` to `true` by eliminating unnecessary extra references).

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Development

No branches or pull requests

4 participants