During protocol conformance checking, open the witness type in addition to the requirement type so we can match conformances for generic witnesses.
Swift SVN r6367
Introduces very basic support for diagnosing ambiguous expressions,
where the source of the ambiguity is a reference to an overloaded
name. Simple example:
t.swift:4:1: error: ambiguous use of 'f0'
f0(1, 2)
^
t.swift:1:6: note: found this candidate
func f0(i : Int, d : Double) {}
^
t.swift:2:6: note: found this candidate
func f0(d : Double, i : Int) {}
^
There's a lot of work needed to make this cleaner, but perhaps it will
ease the pain of developing the library <rdar://problem/14277889>.
Swift SVN r6195
Parse patterns as top-level expression productions, for name binding to validate and convert into proper patterns later. If the type-checker sees an UnboundPattern production survive name binding (currently always), then raise a helpful "patterns don't belong here" error.
Swift SVN r5842
Introduce the LogicValue protocol, which is used to establish when a
particular type can be used as a logical value in a condition. Make
Bool conform to this protocol.
Rename the Builtin.i1-returning Bool.getLogicValue() to
_getBuiltinLogicValue(), because this is meant to be a builtin hook
for the compiler. We can add more underscores here if needed to hide
this further from users.
Move the implementation of _getBool() into C code. It was performing
an 'if' on a Builtin.i1, which does not (and should not!) conform to
the LogicValue protocol. Once more oneof IR generation comes online,
we'll be able to write both this and _getBuiltinLogicValue in Swift
directly.
Swift SVN r5140
When opening generic types, only the type variables for the primary archetypes become syntactic parameters of the BoundGenericType. We still open the associated archetypes; we just don't add them as arguments.
Swift SVN r5052
Provide distinct syntax 'a as T' for coercions and 'a as! T' for unchecked downcasts, and add type-checker logic specialized to coercions and downcasts for these expressions. Change the AST representation of ExplicitCastExpr to keep the destination type as a TypeLoc rather than a subexpression, and change the names of the nodes to UncheckedDowncast and UncheckedSuperToArchetype to make their unchecked-ness explicit and disambiguate them from future checked casts.
In order to keep the changes staged, this doesn't yet affect the T(x) constructor syntax, which will for the time being still perform any construction, coercion, or cast.
Swift SVN r4498
Implement the syntax 'if x then y else z', which evaluates to 'y' if 'x' is true or 'z' if 'x' is false. 'x' must be a valid logic value, and 'y' and 'z' must be implicitly convertible to a common type.
Swift SVN r4407
Implement switch statements with simple value comparison to get the drudge work of parsing and generating switches in place. Cases are checked using a '=~' operator to compare the subject of the switch to the value in the case. Unlike a C switch, cases each have their own scope and don't fall through. 'break' and 'continue' apply to an outer loop rather to the switch itself. Multiple case values can be specified in a comma-separated list, as in 'case 1, 2, 3, 4:'. Currently no effort is made to check for duplicate cases or to rank cases by match strength; cases are just checked in source order, and the first one wins (aside from 'default', which is branched to if all cases fail).
Swift SVN r4359
Add support to the constraint checker for typechecking UnresolvedSuperMemberRef expressions and constructing SuperMemberRef or SuperCall expressions as appropriate. We’ll also need a GenericSuperMemberRefExpr to refer to properties of generic supertypes, but in the interests of demo expedience I’m leaving that case partially-implemented for now.
Swift SVN r4020
Analyze an expression of the form [<tuple contents>] into a call to T.convertFromArrayLiteral(<tuple contents>) for some T conforming to an ArrayLiteralConvertible protocol. Because of some limitations in the constraint checker and protocol conformance checkers, it currently does an ad-hoc conformance check using member constraints. It also currently fails to typecheck for generic container types, and does not provide a default fallback to 'T[]' if unable to deduce a better type from context.
Swift SVN r3953
When matchTypes is trying to match up instances of the same generic type for a Conversion or Construction constraint, it isn't an error for the generic types not to be recursively the same, because a constructor or conversion operator may be available between different instances of the type. Fixes <rdar://problem/13140447>.
Swift SVN r3938
statements. The approach is fairly simple: generate constraints for
both the destination and source expressions, then turn the destination
type into a type containing only rvalues and convert the source
expression to that type.
Swift SVN r2925
using archetypes so that, e.g., an archetype T that conforms to
Ordered can be compared with <. Requires the introduction of
'archetype' constraints, so that we don't run amok and allow the use
of operators in protocols for *any* type that meets the requirements
of the protocol. This may change later, with default implementations,
of course.
The egregious hack introduced in Char.isSpace() works around known,
massive performance problems with the solver's exploration of the
state space. In this case, we have 6 instances of ==, each of which
has 18 overloads, for a large state space. However, we compound the
problem significantly by trying many possibilities for the ~30 type
variables in each state, rather than concluding quickly (as we should)
that most of those branches don't make sense.
Swift SVN r2922
constraint solver produces multiple solutions. The criteria for "best"
are fairly simple: we compare the bindings for each type variable
bound in both solutions:
- If the binding in the first solution is a subtype of the binding
in the second solution, but not vice-versa, the first solution is
at least as good as the second
- If the type variable has a literal constraint on it, and the bound
type in the first solution matches the default literal type for
that literal kind, the first solution is as good as the second.
From there, we follow the obvious rules for picking a winner: if some
of the type variables in the first solution are as good as the same type
variables in the second solution, but none of the type variables are
worse, then the first solution is better.
We can now type-check "1 + 2.0". Take *that*, TypeCheckCoercion.cpp.
Swift SVN r2894
T(x)
where T is the name of a type. This syntax either coerces 'x' to the
type T or, failing that, enumerates the constructors of T and invokes
one of them.
Note that, syntactically, this coercion is syntactically identical to
a function application
f(x)
We distinguish these cases with a simple, syntax-based scheme: if the
'function' subexpression of the application can be trivially
determined to have metatype type, then we consider this a
construction. Otherwise, we assume that it's a function
application. This disallows some crazy coercions---e.g., those that
involve overloaded variables of metatype type---but should feel fairly
intuitive, and it keeps the constraint systems simpler.
Swift SVN r2802
to a type, without removing the lvalueness of the replacement
type. Keeping the lvalueness is important when referring to a
declaration, because that reference might be an
lvalue. Properties/subscripts are working better now.
Swift SVN r2796
constraint-based type checker, include the body of the explicit
closure within the set of constraints. This allows type information to
flow from the body expression, so that we can type-check, e.g.,
map(new Int[N], { $0.toString() })
to a String[] without context information. Fixes <rdar://problem/11229738>.
Swift SVN r2794
conversions. We limit the relationship between the result of the
conversion and the actual expected type to a subtyping relationship,
which effectively limits us to applying a single user-defined
conversion function (rather than a chain of such conversions).
Later, we can consider extending this to a chain of conversion
functions, but that will require us to cope with cyclic conversions
and minimizing conversion sequences (e.g., if A -> B -> C and A -> C
are both possible, we should prefer A -> C).
Swift SVN r2730
difference is that a concrete type's conformance to an existential
type is considered a conversion (but not a subtyping). Relationships
between two existential types are (non-trivial) subtyping relationships.
Swift SVN r2718
system has been "solved", meaning that all type variables have been
bound to concrete types or are completely free. Add the solvedness of
a particular system to the debug output.
Start adding some simple test cases.
Swift SVN r2706
