When lowering SIL builtin ConstantRefs, just stash away the FuncDecl, and pass that decl on to a tweaked version of emitBuiltinCall when the constant is applied.
Swift SVN r4736
+0.0 - ±0.0 == ±0.0, so the correct definition of '-x' is '-0.0 - x'. However, this would be infinitely recursive, so I added an 'fneg' builtin that lowers directly to 'fsub -0.0, %x', and redefined the unary - operators for floats in terms of it.
Swift SVN r4634
Collect the substitutions from SpecializeInsts and use them when emitting an ApplyInst to pass archetype parameters and to reexplode arguments at the right abstraction level for the generic callee. Unfortunately, ArchetypeTypeInfo::allocate() is broken, so alloc_box $T for an archetype type T doesn't yet work.
Swift SVN r4597
Instead of embedding Explosions in IRGenSIL's LoweredValues and trying to use them directly, store an unmanaged vector of llvm::Value*s, and create Explosions as needed. This allows Explosion APIs to behave normally (consuming values out of the explosion) without potentially messing up SIL value-to-LLVM value mappings.
Swift SVN r4309
Implement super.constructor for ObjC superclasses by dispatching the superclass init message with objc_msgSendSuper2. Fixes <rdar://problem/13107128>.
Swift SVN r4288
Replace the more specific Super*RefExpr nodes with a single SuperRefExpr that resolves members of 'this' relative to its superclass. Add an OtherConstructorDeclRefExpr for referring to a constructor as called from another constructor, and use it to represent resolved 'super.constructor' expressions. (It should also be able to represent delegating constructors for free, if we decide we want to add syntax for that.)
Swift SVN r4286
Add 'isObjC' as a property of ValueDecl, and set it during type checking if a class is either explicitly annotated with an [objc] attribute or inherits from an isObjC class, or if a func is a method of an isObjC class. Tweak the ClangImporter and other places that summon magic ValueDecl nodes to set up the decls they synthesize as isObjC. Replace logic in typechecking and IRGen that branched on the 'isObjC' attribute to now branch on the 'isObjC' property of ValueDecls.
Swift SVN r4078
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
Fix up the thunk generator so it knows how to turn byval C arguments back into Swift explosions, so that methods that take NSRects as arguments or give NSRect as their return value can be exported as objc methods.
Swift SVN r4010
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
Previously, we were relying on objc_retain to retain the closure, but
closure contexts aren't actually id-compatible. Now we use a C++ RAII
object for Swift to manage the closure context retain count.
In the process, Joe and I discovered that the closure context was being
passed to the conversion shim at +0; that has now been fixed to be +1.
Swift SVN r3948
Alter CalleeSource and Callee to keep their own internal vector of substitutions and concatentate multiple SpecializationExpr substitutions. Update EmitPolymorphicArguments::emit to emit arguments out of the substitution list based on the generic parameters of the current function type instead of assuming that the substitution list and generic parameter list match up.
Swift SVN r3937
In the StmtChecker, consider a ConstructorDecl or DestructorDecl context to be a function context that returns (). In IRGen for constructors and destructors, set up proper return blocks so that 'return' does the right thing, and in constructors, pretend that the body has no return value even though the underlying constructor mechanism totally returns a value. Fixes <rdar://problem/12950817>.
Swift SVN r3915
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
Recognize super.constructor calls in IRGen and generate them as calls to the superclass initializing constructor. Note that super.constructor code still won't execute just yet because classic IRGen doesn't generate initializing constructors.
Swift SVN r3859
Emit the SIL destructor as a destroying destructor, then emit a deallocating destructor shim that calls into it and then returns the heap size. (The actual deallocation still happens in swift_release--I talked to John about that and I'll fix it later.) This gets the broken SIL/IRGen class tests passing again.
Swift SVN r3838
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
Implement lowering of SIL ClosureInsts by packing the partial arguments into a heap allocation and emitting a thunk to unpack them and apply the closure function, similar to curried entry points. The test doesn't work quite yet because nested FuncDecls don't get visited anymore. I need to replace my hacked SIL path with a proper walk of the SIL module to generate functions and the AST to generate types.
Swift SVN r3817
These let SILGen retain and release arbitrary Explosions without having to work around cleanups. Also remove 'transfer' because I'm dumb and didn't realize 'reexplode' already does the same thing.
Swift SVN r3816
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
Implement IRGen for RefElementAddr so that class accessors work. Add a loadUnmanaged method to TypeInfo classes so that we can populate Explosions without accruing unwanted cleanups.
Swift SVN r3779
Implement SIL-to-IR lowering for allocation, deallocation, load, store, and branching instructions so that local variables and branching control flow can be used. Add a Fibonacci loop test to exercise the new instructions.
Swift SVN r3767
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
The test changes are that we're setting a class body on
some types that we weren't before. For some of these,
this is okay; for others, it's more questionable, but
ultimately not *harmful*.
Swift SVN r3746
