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
type substitution for a nested type reference (Foo.Bar.Wibble) whose
substituted parent reference (Foo.Bar) yields an archetype can simply
look for the appropriate nested type in the archetype.
This allows us to eliminate the hideous ASTContext::AssociatedTypeMap
and simply the archetype builder.
Swift SVN r2438
representation for the nested type:
- If the type is nested within a deducible generic parameter type,
build it as a nested type of that generic parameter type. (The
terminology is bogus)
- Otherwise, look for the member type of the given name and build a
reference to it.
Swift SVN r2426
destructor finds a metatype member (e.g., a typealias), the resulting
access expression should be based on the metatype (possibly
specialized) rather than based on 'this'. Fixes <rdar://problem/11926972>.
Swift SVN r2390
placed on generic parameters and associated types within the generic
parameter clause, expands those requirements out to form the complete
set of requirements, then assigns archetypes for each of the generic
parameters and their nested types (recursively).
Swift SVN r2379
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
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
the various NominalDecl subclasses into a single NominalType* member
in NominalDecl. Use it to make TypeDecl::getDeclaredType() more
efficient/simpler, and simplify the ProtocolDecl/ProtocolType
interaction along the way.
No functionality change.
Swift SVN r2298
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
