The use of 'nocapture' for parameters and return values is incorrect for C++ types, as they can actually capture a pointer into its own value (e.g. std::string in libstdc++)
rdar://115062687
LLVM does type based analysis on sret storage types. This is a problem
with non-fixed types whose storage type does not contain the non-fixed
part.
rdar://73778591
This just eliminates -enable-sil-ownership from all target-swift-frontend and
target-swift-emit-silgen RUN lines. Both of those now include
enable-sil-ownership in their expansion.
Found via the ownership verifier running on IRGen/outlined_copy_addr.swift.
We treat initialization of an existential as a +1 operation, so there is the
possibility that we would have double destroyed a value. In fixing this I
followed what manageOpaqueValue did on the first code path, since it is handling
this case correctly (and using the SGFContext to do so to boot!).
To ensure this is tested, I enabled ownership verification on the test and since
it seems to be exposing a SILGen code path that we aren't testing currently,
converted it into a SILGen test.
They're not used inside the thunk so it's a waste passing them in, and
if they involve private types from a different translation unit we will
get a linking error from referencing the metadata accessor function.
Fixes the test case in <rdar://problem/39470607>, but the more general
problem remains.
When dealing with record types, the outliner had a peephole optimization that is apparently invalid in a corner-case (see new test case)
If we added an archetypes then we *have* to emit type metadata for any containing record type, else we might skip one of the “child” records in our recursive type walk
