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
which other archetypes (such as associated types) are based. Give
primary archetypes an index, to help with recording substitutions in
the near future.
Swift SVN r2239
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
conformance when it is trivial, e.g., when the source type is an
archetype or existential type that conforms to the candidate protocol
or a protocol that implies it. In this case, we don't build a
ProtocolConformance structure (which would be uninteresting anyway).
Extend the definition of ErasureExpr to allow for null entries in the
conformance mappings, when some of the conformance is trivial. IRgen
couldn't handle multi-protocol existential types anyway, so this
change has no impact there (yet).
Swift SVN r2212
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
type is either a protocol type or a protocol composition type. The
long form of this query returns the minimal set of protocol
declarations required by that existential type.
Use the new isExistentialType() everywhere that we previously checked
just for ProtocolType, implementing the appropriate rules. Among other
things, this includes:
- Type coercion
- Subtyping relationship
- Checking of explicit protocol conformance
- Member name lookup
Note the FIXME for IR generation; we need to decide how we want to
encode the witnesses for the different protocols.
This is most of <rdar://problem/11548207>.
Swift SVN r2086
values of existential type, e.g.,
var x : Printable
x.print()
Existential member references reify the type of the implicit object
argument (implicitly, because we have no way of expressing this in the
type system), and replace the types of any other archetypes
with existential types that (don't, but will eventually) conform to
the protocols to which the archetypes conform.
Swift SVN r1963
using the term "unresolved" in expressions for a while, and it fits
for types better than "dependent type."
The term "dependent type" will likely come back at some point to mean
"involves an archetype".
Swift SVN r1962
application expressions that provide a 'this' parameter to a
method. There will eventually be more than just DotSyntaxCallExpr, to
capture the other syntactic (and implicit) forms.
Swift SVN r1924
A user-defined conversion function is an instance method that accepts
an empty tuple and returns a value of the type we're converting to,
has the [conversion] attribute, and is named __conversion. The last of
these restrictions is a temporary hack to work around our inability to
perform a lookup across all extensions for "every function with the
conversion attribute", and shouldn't last too long.
As in C++, we only get one user-defined conversion function. Unlike in
C++, a constructor is not (and cannot) be a conversion function.
Introduce NSString <-> String conversion functions, but leave the
runtime implementations as stubs for Dave to fill in.
Swift SVN r1921
another function type, so long as the source is a subtype of the
target. The subtyping relation is fairly obvious, allowing parameter
renaming, qualification conversions for lvalue types, and
protocol-conformance conversions (at the top level of function
types). It is a strict subset of the allowed type coercions.
The representation of FunctionConversionExpr is temporary. It will
need to account for the capture of the source of the conversion in the
trivial-trivial case.
Swift SVN r1839
in general, not sound. For the limited cases where we did use this
expression kind on lvalues (member access or instance method
invocations on a superprotocol), leave the conversion to the client of
their respective AST nodes (MemberRefExpr, DotSyntaxCallExpr). We may
decide to enrich these ASTs in the future with more information about
the conversion path, but it's not clear that it's actually useful
information for, e.g., IRgen.
Swift SVN r1830
from a protocol to a protocol it inherits. This is a far simpler
operation that the general type-erasure expression, so generate this
AST when we can.
Swift SVN r1813
I'm not completely sure this is the representation we want, but it isn't much code to rip out if we decide to represent it some other way.
While I'm in the area, also fix a case where tuple->tuple conversion wasn't working.
Swift SVN r1748
