ClosureLifetimeFixup: Handle undef partial_apply arguments gracefully

[aschwaighofer]

We have to handle undef partial_apply arguments to handle the following
source gracefully during the diagnosis pipeline.

class TestUndefined {
  private var stringList: [String]!

  func dontCrash(strings: [String]) {
    assert(stringList.allSatisfy({ $0 == stringList.first!}))
    let stringList = strings.filter({ $0 == "a" })
  }
}

rdar://57893008

[aschwaighofer]

@swift-ci Please test

[gottesmm]

A question and a thought.

1. Shouldn't a destroy_value on undef or a destroy_addr on undef just be a no-op? What was the specific crash?
2. I imagine this is a greater problem in the optimizer. I bet you that if we had a pass that changed random values to be undef, we would catch a ton of bugs. Not saying you need to do that here though. For instance, what about mandatory inlining.

Beyond that in the local the code looks ok locally. Can I get my question above answered, then I LGTM?

[aschwaighofer]

We call insertDestroyOfCapturedArguments which calls releasePartialApplyCapturedArg which calls if (arg->getFunction()->hasOwnership()) to figure out whether it should call createDestroyValue.

arg->getFunction() is null.

[aschwaighofer]

@swift-ci Please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 7d09aee

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 7d09aee

[gottesmm]

LGTM!