When we see a '.member' expression in optional context, look for the member in the optional's object type if it isn't found in Optional itself. <rdar://problem/16125392>
Swift SVN r19469
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
Previously, we were relying on user-defined conversions to perform the
final bridging from the Objective-C class type (e.g., NSString) to its
Swift value type (String). That works for NSString <-> String, but not
for arbitrary arrays. Use the bridgeFromObjectiveC() witness instead,
so we can handle:
let obj: AnyObject = ...
let strArr: String[] = obj!
Fixes <rdar://problem/16952771>.
Swift SVN r18422
We had our transition path, and now it's time to kill it because it's
causing problems <rdar://problem/16672558>.
Amusing note: the SILGen test change is actually an improvement. We
weren't rebinding self when performing initializer delegation with the
separated call syntax.
Swift SVN r16707
We are removing this syntax. To stage the move, first error with
Fix-Its to rewrite to the keyword-argument syntax. In a week or so,
we'll remove all of the code supporting the "separated" call syntax.
Swift SVN r15833
Factor an IdentityExpr base class out of ParenExpr, and migrate most of the logic to see through ParenExprs to see through IdentityExprs instead. Add DotSelfExpr as a new subclass of IdentityExpr, produced by parsing 'x.self'.
Swift SVN r14381
An arbitrary value of class metatype cannot be used to construct an
object, because there's no guarantee that a given subclass will
provide that initializer.
Swift SVN r14175
Implement several rules that determine when an identifier on a new
line is a continuation of a selector-style call on a previous line:
- In certain contexts, such as parentheses or square brackets, it's
always a continuation because one does not split statements in
those contexts;
- Otherwise, compare the leading whitespace on the line containing
the nearest enclosing statement or declaration to the leading
whitespace for the line containing the identifier.
The leading whitespace for a line is currently defined as all space
and tab characters from the start of the line up to the first
non-space, non-tab character. Leading whitespace is compared via a
string comparison, which eliminates any dependency on the width of a
tab. One can run into a few amusing cases where adjacent lines that
look indented (under some specific tab width) aren't actually indented
according to this rule because there are different mixes of tabs and
spaces in the two lines. See the bottom of call-suffix-indent.swift
for an example.
I had to adjust two test cases that had lines with slightly different
indentation. The diagnostics here are awful; I've made no attempt at
improving them.
Swift SVN r13843
An expression of DynamicLookup type can be unconditionally downcast to
any class type via the postfix '!'. This will allow one to replace
var w : NSWindow = (nsarray[0] as NSWindow)!
with
var w : NSWindow = nsarray[0]!
The current implementation is fairly limited: it only works when the
operand of '!' is an rvalue of type DynamicLookup, and we don't ensure
that the result is a class type. Nonetheless, it cleans up some of
ListMaker nicely.
This is the first client of disjunction constraints, which were added
in r9142.
Swift SVN r9151
This moves trailing closures from expr-postfix up to the level of
expr, and introduces an intermediate level (expr-basic) for places
that need to parse expressions followed by curly braces, such as
if/while/switch/for. Trailing closures are still restricted to occur
after expr-postfix, although the parser itself parses a slightly more
general and then complains if it got more than an expr-postfix.
Swift SVN r5256
Trailing closure syntax allows one to write a closure following any
other postfix expression, which passes the closure to that postfix
expression as an arguments. For example:
sort(fruits) { |lhs, rhs|
print("Comparing \(lhs) to \(rhs)\n")
return lhs > rhs
}
As a temporary limitation to work around the ambiguity with
if foo { ... } { ... }
we require trailing closures to have an explicit parameter list, e.g.,
if foo { || ... } { ... }
Swift SVN r5210
