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
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
Currently only used for parsing. The immediate intent of these attributes is
to have them behave like [objc] for the purpose of emitting method
implementations; however, they are semantically distinct and should only be
used to expose outlets and actions to Interface Builder.
Swift SVN r3416
Objective-C methods imported from Clang can be part of extensions,
which weren't covered by the existing logic. Note that we currently
ban [objc] methods in extensions written in Swift, a restriction we
may want to revisit.
Swift SVN r3284
rdar://12315571
Allow a function to be defined with this syntax:
func doThing(a:Thing) withItem(b:Item) -> Result { ... }
This allows the keyword names in the function type (in this case
`(_:Thing, withItem:Item) -> Result`) to differ from the names bound in the
function body (in this case `(a:Thing, b:Item) -> Result`, which allows
for Cocoa-style `verbingNoun` keyword idioms to be used without requiring
those keywords to also be used as awkward variable names. In addition
to modifying the parser, this patch extends the FuncExpr type by replacing
the former `getParamPatterns` accessor with separate `getArgParamPatterns`
and `getBodyParamPatterns`, which retrieve the argument name patterns and
body parameter binding patterns respectively.
Swift SVN r3098
In particular, fix a bug where DREs that refer to types were
always given trivial reps because we were trying to emit the
metatype's metatype. This in turn exposes a number of bugs,
including a typechecker bug (where GetMetatypeExpr bases
weren't converted to r-values) and a bug where MREs that
refer to types were always assumed to produce trivial reps.
Swift SVN r3095
protocol witnesses over to the new API. There's some badness
that we're papering over here involving generic types, but
this is a necessary first step.
Swift SVN r3003
dispatch. Currently there is no possibility of override.
This was really not as difficult as I managed to make it
the first time through.
Swift SVN r2960
of a class is part of the class members section and is not
global to the entire class metadata. This is crucial for
correct operation of functions expecting a base-class
metadata object.
That gives us the correct foundation to implement an
optimization under which generic arguments that can be
inferred from the 'this' pointer need not actually be
separately passed. This has the important result of
making all class member functions with the same signature
up to abstraction actually have the same physical
signature.
Swift SVN r2936
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
