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
to avoid some obvious redundancies. This also gives us a
more general framework with which to exploit other ways
in which metadata is known.
Swift SVN r3047
towards optimizing generic calls to derive things from the
'this' pointer, which is actually crucial for virtual
dispatch (to get all methods to agree about how the
implicit arguments are passed). Fix a number of assorted
bugs in metadata emission. Lots of assorted enhancements.
This was proving surprisingly difficult to actually tease
apart into smaller patches.
Swift SVN r2927
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
This is kindof a pain in a few places where the type system
doesn't propagate canonicality. Also, member initializations
are always direct-initializations and so are allowed to use
explicit constructors, which is a hole in our canonicality
tracking. But overall I like the idea of always working
with canonical types.
Swift SVN r2893
