Emit the deallocObject runtime call inside the deallocating destructor for a heap object, instead of inside swift_release. This will allow for heap objects with known size to directly call fast deallocator entry points and potentially custom deallocators in the future.
Swift SVN r5027
To be able to get the dynamic type of a generic value, the 'typeof' operation needs to be part of the value witness for the type. Add 'typeof' to the value witness table layout, and in the runtime, provide standard typeof witnesses for static, Swift class, and ObjC class values.
Swift SVN r5013
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
Find function bodies and emit their local type decls using the AST instead of relying on SILConstants to point the way back to the function bodies.
Swift SVN r4916
Change the destroying destructor entry point ABI to take 'this' as the appropriate type instead of as %swift.refcounted. Emit the deallocating destructor in IRGen when we see the ClassDecl, not when we see the SILFunction for the destructor. This frees us from having to worry about whether a SILFunction came from a destructor decl. We won't be able to reconstruct that once SILFunctions are pre-mangled.
While we're here, repaint some bikesheds so it's clearer that SIL and SILGen work with the destroying destructor.
Swift SVN r4908
Move AbstractCC into SILType and make it an attribute of SILTypes for functions. Add a ConvertCCInst to represent calling convention conversions. Give SILFunctions a linkage attribute. Add logic to SILGen to calculate these attributes for SILConstants based on their attached decls.
IRGen doesn't use these new attributes yet. I'll hook that up when I move mangling over.
Swift SVN r4886
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
handling non-fixed layouts.
This uncovered a bug where we weren't rounding up the header
size to the element alignment when allocating an array of archetypes.
Writing up a detailed test case for *that* revealed that we were
never initializing the length field of heap arrays. Fixing that
caused a bunch of tests to crash trying to release stuff. So...
I've left this in a workaround state right now because I have to
catch a plane.
Swift SVN r4804
Add a runtime function that, given a generic type metadata pointer, allocates a heap object capable of containing a value of that type. This is a first-pass implementation that always does the worst case thing of stuffing the type metadata into the box with the value and using its value witness table to size, align, and destroy the box. Use swift_allocBox to implement ArchetypeTypeInfo::allocate correctly for heap object allocations. This means SIL's alloc_box $T now works for archetypes, and a simple generics test now (almost) compiles through SIL!
Swift SVN r4599
Set up IRGen to emit SIL code that uses top-level-code global variables. Add -sil-i to a bunch of Interpreter tests that use global variables.
Swift SVN r4480
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
When running in immediate mode, generate a global initializer when an extension is defined for an ObjC class that uses the class_replaceMethod runtime function to dynamically add the extension methods to the ObjC class.
Swift SVN r4153
Emit ObjC stubs and categories for methods defined in extensions of ObjC-compatible classes. This makes extensions of ObjC classes available to ObjC in statically compiled code. For immediate-mode code we'll still need to dynamically register extension methods using the ObjC runtime.
Swift SVN r4149
For Objective-C super calls, build an objc_super struct value containing the receiver and class/metaclass object and pass it to objc_msgSendSuper2. For Swift super calls, emit a direct call to the super implementation.
Swift SVN r4023
Push LLVM attribute generation from expandAbstractCC into getFunctionSignature and CallEmission so that they can generate sret and/or byval attributes per-argument according to the calling convention. Copy our bogus rule for emitting sret returns (more than three elements in the explosion) and reuse it to pass large struct values as byvals rather than as explosions. This should be good enough to get both 'NSRect' and
'NSRange', 'NSSize' etc. to pass correctly to ObjC methods. Next step is to set the AbstractCC correctly for imported func decls so that standalone C functions follow the same bogus rule.
Swift SVN r3993
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
Emit separate entry points for the allocating and initializing constructors. 'super.constructor' now works for the small subset of cases for which I've implemented sema support.
Swift SVN r3864
IRGen was generating the exact same signature for the initializing/allocating constructors and destroying/deallocating destructors. Make it do the right thing by typing the initializing constructor as Swift T -> (...) -> T and the destroying destructor as LLVM void(%swift.refcounted*). (This will later change to '%swift.refcounted*(%swift.refcounted*)' pending some irgen/runtime cleanup.)
Swift SVN r3837
Remove the filter that only irgenned SIL functions for FuncDecls so that we emit functions for all SIL decls, and disable the old paths for properties, constructors, and destructors when a SIL module is present. Unfortunately this breaks class constructors because SIL and IRGen don't agree on how initializing constructors should work. I need to sync with John to figure out how to fix that.
Swift SVN r3827
Make the SIL visitor path a bit less hacky by more cleanly separating the AST walk to find types to codegen from the SIL module walk to find functions to codegen. This way, local functions and other such entry points from SIL actually get generated, and the closures test works.
Swift SVN r3820
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 ObjC ABI requires these class fields to be initialized by
resolving symbols from the runtime. So this is a historical
requirement. Note that there is a desire to optimize this
even for ObjC, because in a project with many classes, these
can actually end up representing a significant fraction of
the external non-lazy relocations in the linked image. But
for now we follow the spec, as we must.
The ObjC ABI requires these to be taken from the runtime,
although there is an effort to make them not require external
relocations like this, since in large projects it can actually
add up to a large percentage of the non-lazy external relocs.
3,6d
2i
Swift SVN r3804
Add a path through IRGenModule to optionally codegen FuncDecls using their corresponding SIL Functions when constructed with a SILModule. Jury-rig an IRGenSILFunction subclass of IRGenFunction that does the bare minimum necessary to compile "hello world" from SIL. There are some impedance mismatches between irgen and SIL that need to be smoothed out, particularly the AST-dependent way irgen currently handles function calls. Nonetheless, `swift -sil-i hello.swift` works!
Swift SVN r3759
Introduce a new swift_dynamicCast pair that take in a general metatype
pointer, rather than the more specific class-metatype pointer used for
class downcasts, and grab the class out of that general metatype
pointer, which may actually be an Objective-C wrapper. This is
slightly slower, but it works for the super-to-archetype cases like
T(an_NSObject), where T can have either kind of metadata.
NSTypedArray<T> is actually run-time type checked now, yay!
Swift SVN r3564
This variant of swift_dynamicCast requires us to have data that's
guaranteed to be class metadata, but it's not always natural to
generate class metadata. No functionality change yet.
Swift SVN r3562
We add a new runtime entry point, swift_dynamicCastUnconditional(),
that aborts when the cast fails. We'll probably want to throw an
exception in the future, but this is fine for now.
Swift SVN r3554
Notably, there is still no support for +1 return values,
so we'll leak when doing alloc/init and so on; but this gets
the fundamentals in place. A lot of the extra stuff in here
is dealing with mapping between metatypes and class objects.
Swift SVN r3425
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
When generating IR for the JIT, use sel_registerName() to unique the
selector references we generate. Static code doesn't need this
pessimization. Fixes <rdar://problem/12764732>.
Swift SVN r3403
Note that the constructors we emit don't function yet, since they rely
on the not-yet-implemented class message sends to Objective-C
methods.
Swift SVN r3370
The principal difficulty here is that we need accessing the
value witness table for a type to be an efficient operation,
but there (obviously) isn't a VWT field for ObjC classes.
Placing this field after the metatype would tend to bloat
metatypes by quite a bit. Placing it before is best, but
it introduces an unfortunate difference between the address
point of a metatype and the address of the global symbol.
That, however, can be fixed with appropriate linker support.
Still, for now this is rather unfortunately over-subtle.
Swift SVN r3307
First, keep track of each of the selectors we emit and dump them into the
llvm.used global so that they don't get thrown away by the
optimizer. Second, emit Objective-C module-level named metadata so
that the linker knows it needs to unique selectors. Otherwise,
uniquing doesn't happen when Swift code is compiled into a separate
dylib.
Swift SVN r3287
