The following program crashed when compiled with the Swift 5.7 and 5.8 compilers:
```
@available(macOS 12, *)
@_backDeploy(before: macOS 99)
public func foo<T>(_ t: __owned T) {
print("foo")
}
class C {
deinit {
print("deinit")
}
}
foo(C())
print("done")
```
```
> ./test
foo
deinit
[1] 49162 segmentation fault ./test
```
The root cause is that generated SIL for the back deployment thunk for `foo(_:)` included its own `destroy_addr` instruction for the value of `t`, but didn't copy the parameter before passing it to the real function implementation which also destroys the value. The fix is to forward ownership of the parameter values to the called function, which causes cleanup generation to be skipped.
Resolves rdar://104436515
If the emission of a function is delayed via `emitOrDelayFunction()`, then the function is recorded on a list of delayed functions. If the delayed function is later referenced, then the function moves from the delayed list to the "forced" list which will cause it to actually be emitted later. The implementation of `emitOrDelayFunction()` had a bug when called twice for the same delayable function - it would emit that function prematurely if the function moved to the forced list between the two invocations. Later, during forced function emission a multiple definitions of symbol diagnostic would be emitted since the function was not empty.
This issue could be triggered by `@_backDeploy` functions that have auxilary delayable helper functions (e.g. defer blocks). SILGen visits `@_backDeploy` functions twice (once for the copy of the function emitted into the client and once for the resilient copy of the function) so `emitOrDelayFunction()` is called twice for each of the helper functions and the helper functions could become referenced between the two calls.
The fix is to check for an existing entry in the forced functions list before delaying or emitting a delayable function.
Resolves rdar://102909684
Per Swift Evolution feedback, back deployed functions should be allowed to be inlinable, even though this means that the version of the function in the library may not always be exectued when it is otherwise available.
Resolves rdar://102792806
APIs with a variety of function signatures (inout parameters, throwing, generic, existential parameters and return values, etc.) are exercised to verify SILGen for these cases.
