binary operator for a given set of argument types. When the argument types
are not dependent or error types, include them in a short single error
diagnostic, and not separated in a separate note.
Swift SVN r1488
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
generic over the type of the base. By "generic" I mean that it's
looked up by prepending the word "Slice" to the name of the base
type.
Swift SVN r1464
printing the operator, adjusting the diagnostic to point to the operator
and not the second operand, properly highlighting the ranges of the operands,
and printing out the types of the operands when appropriate.
Printing out the types is very useful when trying to understand the mismatch.
Note: I only partially know what I am doing at this stage. This feels a bit
kludgy, as the "cast<>"s reek of not enough implicit invariants being documented
in the ASTs themselves.
Fixes <rdar://problem/11266762>
Swift SVN r1449
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
This has the side-effect that you can't explicitly refer to an operator* with "swift.*", etc., but per discussion with Doug, that's probably okay.
Swift SVN r1443
provide a mapping back to that variable. Teach the mangler to provide
a special mangling for such functions (__getVarName,
__setVarName). The mangling will undoubtedly change later, but the
point is that it will need to match the functions generated for
a resilient variable.
Swift SVN r1432
PatternBindingDecl to the DeclContext. Do the same for the get/set
functions for a property, so we don't need to perform 'deep' setting
of the DeclContext. This is simpler, although it makes pretty-printing
the AST a bit more difficult.
Swift SVN r1428
struct/oneof/class extension, making them instance methods. Normal
variables are still not allowed in these contexts, however.
The fact that we set DeclContexts late causes some consternation here,
because it's not clear just how far we need to recurse in
DeclContext. I've done enough to make properties work, but I'm still
rather uneasy about the current state of affairs.
Swift SVN r1423
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
and is just an unmanaged pointer. Also, introduce a basic swift.string type.
This is progress towards rdar://10923403 and strings. Review welcome.
Swift SVN r1349
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
logic. This eliminates spurious diagnostics when attempting to coerce
(for overload resolution) between lvalues and rvalues. Also, improve
error recovery and diagnostics when dealing with an incorrect '&' in
the source.
Swift SVN r1344
I haven't really carefully considered whether existing type-checking etc. is correct for the main module (I think the name-binding rules need to be a bit different?), but it seems to work well enough for the obvious cases.
This is enough to get the one-liner "println(10)" to print "10" in "swift -i" mode, although the path to swift.swift still needs to be explicitly provided with -I.
Swift SVN r1325
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
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
