This introduces support for the syntax
Derived(baseObj)
to downcast from a class type to one of its subclasses. This still
needs more language design and implementation work, including:
- This overloads the X(y) syntax again, which already means either
"coerce y to type X, performing implicit conversions if necessary"
or "construct a value of type X from y". It's no actually ambiguous,
because the first case won't apply for downcasts and the second case
is limited to value types, but it makes me wonder whether we want a
different syntax for the first case.
- We need this to be a checked cast, but don't have the runtime
infrastructure to do so yet. I've left this as a FIXME.
However, the Objective-C importer is fairly useless because everything
that creates an object returns an "id", "id" maps to "NSObject", and
then the type system doesn't let you get from NSObject back to the
type you care about. So, this lets you explicitly do the cast.
Swift SVN r3279
No functionality change: the only subclass is CoerceExpr, for cases
where the user has forced an expression to a given type, e.g., Int32(17).
Swift SVN r3278
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
conversions on metatypes; at runtime it has no effect,
since those conversions are always trivial. Fix a number
of bugs involving the conversion of metatypes, in both
typecheckers.
Swift SVN r3055
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053
for varargs). This is incomplete, but we can already lower this:
var va2 : (Int...) = (1,2,3)
to this CFG:
%15 = tuple (%4, %9, %14)
%16 = alloc_array element type=Int, 3
%17 = tupleelement %16, 1
%18 = tupleelement %15, 0
%19 = store %18 -> %17 [initialization]
%20 = index_lvalue %17, 1
%21 = tupleelement %15, 1
%22 = store %21 -> %20 [initialization]
%23 = index_lvalue %17, 2
%24 = tupleelement %15, 2
%25 = store %24 -> %23 [initialization]
Next, we need to call the injection function to turn an initialized heap
allocation into Slice<T>... which requires a bunch of generic support.
To get this far, this patch:
- Introduces index_lvalue for indexing over array elements (striding lvalues)
- Introduces alloc_array.
- Renames RequalifyInst to TypeConversionInst and generalizes it to handle
FunctionConversionExpr.
Swift SVN r2988
member of a oneof/struct/class/extension to support types nested
within generic classes, e.g., Vector<Int>.ElementRange.
Most importantly, nominal types are no longer inherently canonical. A
nominal type refers to both a particular nominal type declaration as
well as its parent, which may be non-canonical and will vary. For
example, the variance in the parent makes Vector<Int>.ElementRange and
Vector<Float>.ElementRange different types.
Introduce deduction and substitution for nominal types. Deduction is
particular interesting because we actually do allow deduction of T
when comparing X<T>.Inner and X<Int>.Inner, because (unlike C++) there
is no specialization to thwart us.
Swift SVN r2507
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
have a record of how the member is being specialized for the given
context. To do this, I also had to patch up the DeclContext for
template parameters.
Swift SVN r2483
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
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
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
semantics into the AST library where they don't belong. These were
made obsolete by the recent TypeCheckExpr::build(Member)?RefExpr()
refactoring.
Swift SVN r2222
reference expressions, introducing two routines on TypeChecker
(buildRefExpr and buildMemberRefExpr) that are intended to be the sole
generators of ASTs.
Updated all but one caller for member reference expressions, the
terrible MemberLookup::createResultAST(), which still calls into the
AST library to build nodes.
Swift SVN r2219
base of the expression is ignored, as it will be for references to
static member functions or when the base is actually of metatype
type. Then, always also one to access the type of the base, even if
it's a metatype type.
Use this information to simplify our handling of archetype member
reference expressions, which can refer to either members of the
meta-archetype or of an instance of the archetype. This allows us to
refer to an instance methodr of an archetype type (e.g., T.method) and
get back its curried form ([byref] T) -> inputs -> result.
Swift SVN r2218
used in the very narrow case where we were converting from one
protocol type to another (super) protocol type. However, ErasureExpr
now handles this case via its null conformance entries (for the
"trivial" cases), and can cope with general existential types where
some conversions are trivial and others are not.
The IR generation side of this is basically just a hack to inline the
existing super-conversion code into the erasure code. This whole
routine will eventually need to be reworked anyway to deal with
destination types that are protocol-conformance types and with source
types that are archetypes (for generic/existential interactions).
Swift SVN r2213
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
