Code may end up indirectly using a witness table for a Clang-imported type by inlining code that used the conformance from another module, in which case we need to ensure we have a local definition at hand in the inlining module so we can have something to link against independently. This needs to be fixed from both sides:
- During serialization, serialize not only witness tables from the current module, but from Clang-imported modules too
- During deserialization, when the SILLinker walks a loaded module, ensure that all shared conformances get deserialized, including those from ApplyInsts and inherited/associated type protocol requirements.
Fixes rdar://problem/38687726.
Also, add a third [serializable] state for functions whose bodies we
*can* serialize, but only do so if they're referenced from another
serialized function.
This will be used for bodies synthesized for imported definitions,
such as init(rawValue:), etc, and various thunks, but for now this
change is NFC.
Having a separate address and container value returned from alloc_stack is not really needed in SIL.
Even if they differ we have both addresses available during IRGen, because a dealloc_stack is always dominated by the corresponding alloc_stack in the same function.
Although this commit quite large, most changes are trivial. The largest non-trivial change is in IRGenSIL.
This commit is a NFC regarding the generated code. Even the generated SIL is the same (except removed #0, #1 and @local_storage).
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
Some AST nodes and SIL instructions need to reference conformances for a
particular type. If that type was imported from Clang, however, the
conformance may not exist when the AST node or SIL function gets deserialized
later. The SIL case is the problem case: fragile SIL code may contain a
reference to a conformance never mentioned in the AST of the code being
compiled, and since conformances are synthesized on demand during type-checking,
this will lead to a crash. SIL deserialization isn't supposed to be doing
work on its own (though it ~can~ import new Clang decls at the moment), so
the best answer is to serialize the conformances directly, like we would with
specialized or inherited conformances.
We can probably do better here in the long run (we don't even unique
conformances like this within a module), but this should at least handle the
immediately known problem cases.
rdar://problem/18669402
Swift SVN r22857
