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
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
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
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
expressions when no value is required. Teach IR-gen
to emit DotSyntaxBaseIgnoredExprs as known function
references with possibly non-trivial semantics.
Undo the change to getSemanticsProvidingExpr().
Swift SVN r1238
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
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
empty tuple as an argument. This should be restricted even more (rdar://10983400)
but this eliminates the most surprising cases at least.
Swift SVN r1165
