e.g. "foo is \(i+j)". This implements rdar://11223686
Doug implemented all the hard parts of this. I ripped out support for nested string
literals (i.e. string literals within an interpolated string), which simplified the
approach and defined away some problems with his patch in progress. I plan a few refinements
on top of this basic patch.
Swift SVN r1738
where overloading based on the indices is insufficient to select an
overload candidate. Implement type coercion for overloaded subscript
expressions, so that the context can help push overload resolution
along.
Swift SVN r1516
to the type named by A (when A is in fact a direct reference to a
type). If that coercion would fail, then fall back to invoking a
constructor. Fixes <rdar://problem/11272190>.
Swift SVN r1472
member of an object. This expression kind is currently used to refer
to properties within an object, but will eventually be extended to
refer to fields as well (once we make StructDecl real).
Swift SVN r1445
oneof/struct/protocol within a static method. The lookup is performed
on the metatype (as one would get when using qualified syntax
Type.member). Add tests to verify that this provides proper
overloading behavior.
As a drive-by, actually set the type of the implicit 'this' variable
during name binding for a non-static method.
Swift SVN r1394
argument is the implicit 'this' argument. Add a number of overloading
tests for overloaded member access, which naturally exercises these
source locations.
Swift SVN r1390
syntax when name lookup finds multiple candidates. Overload resolution
is then used to select the best candidate and map the overloaded
member reference expression down to DotSyntaxCallExpr or
DotSyntaxBaseIgnoredExpr, as appropriate.
This implements part of <rdar://problem/11071641>, so that simple
overload resolution works, but there is still a bit of cleanup to do.
Swift SVN r1366
notion of a reference to a set of declarations. Introduce one derived
class, OverloadedDeclRefExpr, which covers the only case we currently
handle for overload resolution [*]: a direct (unqualified) reference
to an overloaded set of entities. Future subclasses should handle,
e.g., overloaded member references such as a.b or a.b.c.
[*] Ugly hacks for static methods notwithstanding
Swift SVN r1345
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
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
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
inform conversion ranking about auto_closure, and rip out the
CR_AutoClosure implicit conversion. Our conversion ranking is
now completely trivial: we either have an identity conversion
or an invalid one - no crazy implicit conversions (still have
tuple shuffles etc though).
Swift SVN r1192
