not being called directly. We previously had a simplistic
implementation that required exact type matches; loosen this to simply
require coercion, as well as diagnosing ambiguities/lack of suitable
candidates.
Swift SVN r1316
single-parameter functions with a literal argument. The argument
therefore had unstructured dependent type, and there was no reason to
reject it in the first place.
Swift SVN r1313
types. Use this simple overload resolution scheme in both type
checking and type coercion, simplifying both code paths a bit.
There is one significant semantic change here: we allow overload
resolution to operate on (structured) dependent arguments, which
allows for more overload filtering before we come in with the type
coercion hammer. For example, we can now properly type-check
var x : int32;
x + 0;
Swift SVN r1310
one that performs the coercion on the AST and produces diagnostics for
any problems, and one that simply determines whether the coercion
would succeed. The former already existed (as
TypeChecker::convertToType), while an approximation of the latter was
already implemented as Expr::getRankOfConversionTo(). Unifying these
code paths addresses several issues:
- Lots of redundancy in the code for computing these two properties,
which causes bugs. For example, Expr::getRankOfConversionTo()
wasn't able to handle literals (!).
- Determining whether a conversion is possible will need the full
power of the type checker, e.g., to deal with closures in cases
like:
func f(g : (int, int) -> int);
func h() { f({$1 + 0}); }
Although this is not handled correctly now.
I have opted not to adopt Clang's ImplicitConversionSequence (or
InitializationSequence) design, which computes a record of the steps
needed to perform the conversion/coercion and later applies those
steps, because we don't need that complexity yet. If we start
introducing more implicit conversions into the language, we'll revisit
this decision.
Swift SVN r1308
expression will always be a two-element tuple, but it may not always
be a tuple literal. In the near future, it could also be a tuple
shuffle.
Swift SVN r1299
Unlike Type, it implements equality operators. It is returned by Type->getCanonicalType().
This adopts it in the minimal places required to get the build to work, it would also be nice
to switch IRGen to canonical types and use it there.
Swift SVN r1298
type with one or more elements of dependent type. Previously, an
expression such as (x, 5) would have the (unstructured) dependent
type, limiting our ability to type-check the subexpression 'x'
early. Now, if 'x' has type 'int' (for example), this expression will
now have the type (int, <<unstructured dependent type>>).
Extend coercion of a tuple to tuple type to handle coercion to
(structured) dependent tuple types, coercing element-by-element. This
code is very lightly tested and may still need to be restructured.
Swift SVN r1294
or binary context. This allows us to discard binary "-" candidates when in
a unary context. This is enough to resolve the last ambiguity, implementing
<rdar://problem/11088443> The expression "-1" always has type int
Swift SVN r1257
It might be possible to save some memory by breaking the AnonClosureArgExpr linked list during type-checking... not sure if that's worthwhile.
Swift SVN r1248
qualifier, making sure that variables end up so-qualified by
default. Add a RequalifyExpr to capture the act of adding
qualifiers (to form a supertype) to an l-value.
Swift SVN r1236
Teach Expr::getSemanticsProvidingExpr to look through DotSyntaxBaseIgnoredExpr.
Start generating DotSyntaxBaseIgnoredExpr for all dot syntax exprs where the base is
ignored (e.g. "Builtin.mul_i32"), which preserves a lot more source location information
and is general goodness for the AST.
Swift SVN r1232
to properly represent its newly generalized role. It is formed
for things like "swift.print" where swift is a module type and is
evaluated and ignored.
Swift SVN r1230
