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
method to initialize the members. This doesn't matter so much
for structs (the generated IR is essentially equivalent except for
small structs), but on classes, we don't want to make "new X" generate
code that knows about metadata/destructors/etc for the class X.
Also, make sure classes always have a constructor. (We haven't really
discussed the rules for implicitly declared constructors, so for now,
the rule is just "generate an implicit constructor if there is no
explicit constructor". We'll want to revisit this when we actually
design object construction.)
Swift SVN r2361
types. Mostly untested. As part of this, I changed the
order in which we emit erasures: now we evaluate the
operand in-place and only then write the protocols in.
This makes it slightly more likely that a generic
optimization will be able to devirtualize.
Swift SVN r2356
Add a couple other misc pieces necessary for semantic analysis of members of
generic types. We're now up to the point where we can actually construct a
useful AST for small testcases.
Swift SVN r2308
resolution. When we see a polymorphic function type, we substitute
"deducible generic parameter" types for each of the generic
parameters. Coercion then deduces those deducible generic parameter
types. This approach eliminates the confusion between the types used
in the definition (which must not be coerced) and the types used when
the generic function is referenced (which need to be coerced).
Note that there are still some terrible inefficiencies in our handling
of these types.
Swift SVN r2297
add an alternate entry-point called convertFromASCIIStringLiteral which is called for
string literals which contain only ASCII codepoints, and add an optional byteLength
argument for the conversion. <rdar://problem/11764780>.
I've also tentatively changed swift.String to use the new convention; Dave,
please review.
Swift SVN r2290
