Teach IRGen to honor the linkage of SILWitnessTables, and teach SILGen to emit witness tables and protocol witness thunks for external definitions with shared linkage. Fixes <rdar://problem/16264703>.
Swift SVN r14908
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
We're mostly not that bad about this right now, but lazy
emission is going to wreak havoc.
Note that SILGen itself doesn't really make very good decisions
about the order in which to emit functions, but step one
towards fixing that is actually respecting it.
Swift SVN r14200
It was convenient to just assume that the SILModule defines
the deallocating destructor function. This should probably
be represented somehow in e.g. the sil_vtable instead of
being an implicit dependency.
Swift SVN r12412
Note that this lowering currently assumes that the static type of the class is its dynamic type. This should be a flag on the dealloc_ref instruction, not an assumption.
Swift SVN r12144
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
SILGen eagerly produces witness tables for all of the conformances defined in the module, which is what we want in order to make them runtime-unique. Have IRGen follow suit. This should address a ton of radars about breakage with non-unique conformances once SIL witnesses are turned on. We will need some runtime machinery to handle witness tables with dependent fields, but since we currently ignore the associated type fields of witnesses, we can get away with emitting direct references to all witness tables for now.
Swift SVN r11608
Produce protocol descriptors when we see a protocol definition in the current module. If the protocol is @objc, go through the existing path for generating full Protocol* metadata for objc objects; otherwise, emit our layout-compatible but strong-external-linkage Swift protocol descriptor record.
Swift SVN r9867
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
Add a SILLinkage mode "Deserialized" to make sure IRGen will emit
hidden symbols for deserialized SILFunction.
Inside SIL linker, set Linkage to external if we only have a declaration for
a callee function.
Both sil block and decl block in a module can emit an array of substitutions.
To share the serialization between SILSerializer and Serializer, we modify
the interface to pass in the abbreviation codes to write functions and to
pass in a cursor to read functions.
We now correctly handle the serialization of Substitutions in SpecializeInst.
For a deserialized SILFunction, we now temporarily set its SILLocation and
DebugScope to an empty FileLocation. Once mandatory inliner sets the SILLocation
to the location of ApplyInst, a null SILLocation and a null DebugScope
may work for a deserialized SILFunction.
Update testing cases to reflect that we are now inlining transparent functions
from modules, or to disable SILDeserializer for now (I am not sure how to update
those testing cases).
Swift SVN r8582
Lazily-generated currying thunks will require the same IR-level linkonce_odr linkage as clang thunks currently do, so generalize the name of the existing SIL-level linkage specifier 'clang_thunk'.
Swift SVN r8122
Among other things this enables mangled names for tuples.
This adds a pointer to the DeclContext to SILFunction and which is used
to provide the necessary context to the Mangler.
Fixes rdar://problem/14808764 and rdar://problem/14813658.
Swift SVN r8070
We need to handle three cases:
- If a protocol conformance has no associated types, or the associated type witnesses all have statically resolvable metadata, we can expose a *direct* witness table symbol.
- If a protocol conformance has associated types with runtime-instantiated metadata, we need to gate the witness table behind a *lazy* initializer function to fill in the metadata fields.
- If a protocol conformance has associated types where the type or one of its conformances are *dependent* on its parent's generic parameters, we need to instantiate multiple witness tables at runtime.
Swift SVN r6805
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
the debug info, to aid the debugger in figuring out the implementation
language of a given type in multi-language environments.
FYI, where applicable, we also emit the
DW_AT_APPLE_runtime_class(DW_AT_lang_Swift) attribute.
The demangler accepts type names with the "_Tt" prefix without the --type
switch.
Swift SVN r6714
their types.
- DebugTypeInfo holds all type info we need to emit debug information.
- Type info is limited to name, location, and storage size.
- As a side-effect: verbose LLVM IR allocas in debug builds!
Swift SVN r5980
Sever the last load-bearing link between SILFunction and SILConstant by naming SILFunctions with their mangled symbol names. Move the core of the mangler up to SIL, and teach SILGen how to use it to mangle a SILConstant.
Swift SVN r4964
Replace 'constant_ref' with 'function_ref', which references a SILFunction directly, and 'global_addr', which references a global variable VarDecl. Get rid of the SILConstant-to-SILFunction mapping in SILModule and replace it with an ilist of SILFunctions. Allow SILFunctions to be 'external' by not having any blocks in their body.
For now, SILFunctions still carry around their SILConstant "name", because name mangling and IRGen still rely on access to the original decl in order to recover IRGen information, which unfortunately leaves IRGen's CodeRefs in a gross, awkward intermediate state. Lifting mangling, AbstractCC, and other linkage attributes to SIL should clear up this up.
Swift SVN r4865
CapturingExprs get mapped to referenceable SILConstants by SILGen instead of getting emitted in-place as in IRGen, so they need LinkEntities and mangling. For now I just mangle them all to "closure", which matches what old IRGen does.
Swift SVN r4477
Add a mangling for 'block converter' functions and for [objc_block] function types. [objc_block] types also need their own HeapTypeInfo representation that uses ObjC retain/release. When we see a BridgeToBlockExpr, feed the function pointer and context from the Swift closure to the external conversion function and hope we get a block back.
Swift SVN r3899
and non-deallocating destructors and allocating/non-allocating
constructors.
Non-deallocating destructors might not play well with ObjC
classes; we might have to limit them to pure-swift hierarchies.
No functionality change except that I decided to not force
destructors to have internal linkage unconditionally.
Swift SVN r3814
The interesting thing here is that we need runtime support in
order to generate references to metatypes for classes, mostly
because normal ObjC classes don't have all the information we want
in a metatype (which for now just means the VWT pointer).
We'll need to be able to reverse this mapping when finding a
class pointer to hand off to, say, an Objective-C class method,
of course.
Swift SVN r3424
uncurrying level, which is something I find myself passing around
quite a bit. Make sure that it can propagate getter/setter
references in the same way.
Swift SVN r2902
the metadata objects for classes. This is currently only
done for methods defined in the main class body, and it's
(naturally) totally fragile, and it's screwed up in a
couple known ways w.r.t. generic classes: there's no
thunking when the overrider differs by abstraction from
the overridden method, and methods on classes currently
expect to get all the type arguments passed directly
and thus will disagree in signature from members of
non-generic classes. Also, of course, we're not using
any of this in the call infrastructure. But it's progress.
Swift SVN r2901
