Mangling is still a hack, pending a better type AST. Fixed
a bug where arguments passed indirectly were not being destroyed
by the callee (when passed by value). Changed some of the protocol
signatures to use the generic opaque pointer type, making the
types a bit more self-documenting in the IR.
Swift SVN r2274
There are currently two places where you can use a static function defined on a protocol:
on an object with the type of the protocol (discarding the base), and on an archetype in a generic function. The AST for the protocol object case is probably okay;
the AST for the generic case is almost certainly wrong, but that whole area isn't really stable at the moment anyway. The proposal in rdar://problem/11448251 will
add a third way: operators on protocols will be found by overload resolution. (Having static functions on protocols opens up the possibility of metaprotocols,
but I don't think I need to worry about that for the moment.)
Swift SVN r2211
wrap it in an 'id' type in the standard library.
Also fix a bug noticed by inspection where initWithTake for
function types wasn't entering a cleanup for the taken value.
This probably doesn't matter for existing possibilities, but
it's potentially important under exceptions.
Swift SVN r1902
allows access to any LLVM IR intrinsic that has types that can be mapped
to swift types. Notably, this excludes vector stuff, but there is a lot
of other goodness that can now be poked at.
Swift SVN r1890
first, we weren't registering the cleanup for the temporary
if it needed materialization, and second, we were potentially
double-consuming cleanups associated with the l-value, e.g.
subscript indices.
Swift SVN r1631
pairs in extensions. The AST here is a little wierd; I don't
really get why there needs to be a PatternBindingDecl here.
It's easy enough to ignore.
Swift SVN r1592
This intentionally changes the mangling of variable getters and
setters so that we can have a reproducible mangling that doesn't
depend on things like the variables names, which is important
for resilience. It's not currently important for subscripting,
although equally I see no reason to mangle in the subscript
pattern name.
Swift SVN r1590
exactly how the arguments are emitted. Introduce a new code path
which emits arguments from existing Explosions (possibly of the wrong
resilience level). Use that code path to implement getter/setter
code for MemberRefExpr l-values. This is just a checkpoint for the
latter two parts, but the ApplyExpr path is working correctly in the
new framework, which is worth a commit.
Swift SVN r1589
