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
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
in SpecializeExpr, so that we have complete substitution and
protocol-conformance information. On the IR generation side, pass
witness tables for all of the archetypes (again, including derived
archetypes) into generic functions, so that we have witness tables for
all of the associated types.
There are at least two major issues:
(1) This is a terribly inefficient way to pass witness tables for
associated types. The witness tables for associated types should be
accessible via the witness tables of their parent. However, we need
more information in the ASTs here, because there may be additional
witness tables that will need to be passed for requirements that are
placed on the associated type by the generic function itself.
(2) Something about my test triggers a void/non-void verification failure
in the witness build for an instance function whose abstracted form
returns an associated type archetype and whose concrete form returns
an empty struct. See the FIXME in the test.
Swift SVN r2464
in a digit. This penalizes the manglings of things using
builtin types but is kinder to the manglings of tuples.
Also, invent a not-unreasonable mangling for generic function
types and archtypes within them.
Swift SVN r2461
non-generic nominal types to encode the type kind, and add
substitutions for certain very common standard types while
we're at it. Sorry, Howard.
Swift SVN r2455
base type (e.g., the archetype type, when we're in a generic function)
used to refer to that operator as a member, e.g., given
func min<T : Ord>(x : T, y : T) {
if y < x { return y } else { return x }
}
'<' is found in the Ord protocol, and is referenced as
archetype_member_ref_expr type='(lhs : T, rhs : T) -> Bool' decl=<
(typeof_expr type='metatype<T>'))
using a new expression kind, TypeOfExpr, that simply produces a value
of metatype type for use as the base.
This solves half of the problem with operators in protocols; the other
half of the problem involves matching up operator requirements
appropriately when checking protocol conformance.
Swift SVN r2443
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
