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
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
This requires us to potentially copy the value witness tables for
generic struct types as part of computing layout, but that's not
the end of the world (although it will rely on a future patch
to split value witnesses out from protocol witness tables).
Oh, and add a value witness for stride, changing Builtin.strideof
to use that.
Swift SVN r2829
is really a deficiency in TypeInfo::initializeWithTake, which
is now virtual and not implemented in TypeInfo anymore. This
fixes rdar://problem/12153619.
While I'm at it, fix an inefficiency in how we were handling
ignored results of generic calls, and add 4 new builtins:
Builtin.strideof is like sizeof, but guarantees that it
returns a multiple of the alignment (i.e., like C sizeof,
it is the appropriate allocation size for members of an
array).
Builtin.destroy destroys something "in place"; previously
this was being simulated by moving and ignoring the result.
Builtin.allocRaw allocates raw, uninitialized memory, given
a size and alignment.
Builtin.deallocRaw deallocates a pointer allocated with
Builtin.allocRaw; it must be given the allocated size.
Swift SVN r2720
Builtin.ObjectPointer, and Builtin.RawPointer. I don't really like the way
these builtins are defined (specifically, the part where messing up
gives a mysterious IRGen error), but it's workable. <rdar://problem/11976323>.
Swift SVN r2585
a lot closer to successfully emitting the polymorphic-min-over-ranges
example; the main blocker right now seems to be that the witness
for a static member function is not, in fact, a static member
function at al, but a freestanding function. That's legitimate,
but it probably needs some shepherding through the witness
system.
Swift SVN r2532
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
