the appropriate slice type and check the bounds. The
first bound must be a literal or a type with a
getArrayBoundValue method, which has the same recursive
nature as getLogicValue (i.e. it can return a type that
has a getArrayBoundValue that returns an integral type,
but that's it; it's capped at one hop). The rest
of the bounds must be empty (meaning a slice) or
constant under the same conditions as fixed-size
array types.
Swift SVN r1501
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
candidates both the elements of a oneof and any methods with the same
name as the oneof (which is our current hack for a constructor).
Given var x : Int, we can now write Double(x) rather than Double.Double(x).
Swift SVN r1469
element, add that element as a member lookup result but don't stop
there: also find extension functions with that same name.
Fixes <rdar://problem/11270370>.
Swift SVN r1468
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
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
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
