Issue Description:

Recent versions of Swift have a more effective Copy Propagation pass that much more aggressively shortens the lifetime of some Swift objects. This has revealed some latent bugs in several projects, including [swift-corelibs-foundation| apple/swift-corelibs-foundation#2994].

In general, Swift has a very clear rule about lifetime: an object can be deallocated at any time after its last point of use. This is a clear guide, and easy enough to follow. However, there is a more subtle case: how does this apply to self in member functions?

To make this concrete we can consider a (contrived) example:

public final class WeirdFileThingy {
    private let fd: CInt
    init(_ x: CInt) {
        fd = x
    }
    deinit {
        close(fd)
    }
    public func read() -> UnsafeMutableRawBufferPointer {
        let localFD = self.fd
        var data = UnsafeMutableRawPointer.allocate(count: 100, alignment: 1)
        let length = data.withUnsafeMutableBytes {
            Darwin.read(localFD, $0.baseAddress, 100)
        }
        precondition(length != -1 || errno != EBADF)
        return UnsafeMutableRawBufferPointer(start: data, count: length)
    }
}

The question is, can the call to Darwin.read fail with EBADF and hit the trap on the following line? The answer to this question will depend on whether the deinit for this class is allowed to execute after the let localFD = self.fd line (the last use of self in this function), or whether self is guaranteed to be at +1 until the end of the member function.

As @gottesmm has noted, there are two vectors to this. The first is the question of whether this code is safe today. Areas of particular concern are around inlining. The second is the question of whether Swift should formally guarantee that self is always retained throughout the entirety of a member function invocation. Today I don’t think we have clear guidance for users as to what the lifetime of self is in this situation, and I think we should come to a clear guarantee one way or another.