when turning integer constants into floating-point values.
Teach IR-gen to fold stdlib convertFromIntegerLiteral and
convertFromFloatLiteral calls.
Update a bunch of tests.
Swift SVN r2485
return type, not the original. We were getting away with it
as long as we had a final address, but we won't always have
a final address, as in this test case, where we're ignoring the
result.
Swift SVN r2421
by abstraction from the concrete return type.
This basically gets generic calls working totally as long
as there's no remapping required.
Swift SVN r2402
analysis for patterns.
Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
can hold a reference to the same expression.
Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.
Swift SVN r2370
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
