a capture list hung off the CaptureExpr it was associated with. This made
sense lexically (since a capture list is nested inside of the closure) but
not semantically. Semantically, the capture list initializers are evaluated
outside the closure, the variables are bound to those values, then the closure
captures the newly bound values.
To directly represent this, represent captures with a new CaptureListExpr node,
which contains the ClosureExpr inside of it. This correctly models the semantic
relationship, and makes sure that AST walkers all process the initializers of the
capture list as being *outside* of the closure.
This fixes rdar://19146761 and probably others.
Swift SVN r23756
Provides consistency in behavior, particularly in enum raw values, where we reject non-literals. Factor out a common NumberLiteralExpr base for integer and float literals that handles the common sign and representation stuff. Fixes rdar://problem/16504472.
Swift SVN r23390
The issue is reproducible in erroneous code scenario when a string literal
has invalid stuff inside interpolation segment, like: “... \( abc } ) ...”.
In this case we used to do some magic for switching context inside the string
and parse the interior of \(...) as regular expression list, but expected that
the parsing finishes at closing “)” which does not necessarily true in case
the code has errors.
The assertion was replaced with an error diagnostics.
Swift SVN r23296
This patch extends the AST and parsing of #os(...) queries to permit queries for
multiple platforms, e.g., #os(OSX >= 10.10, iOS >= 8.0). It also improves
parsing error recovery.
Swift SVN r22154
This patch adds a new 'pound_os' token, a new case for it in parseExprPostfix, and parsing of platform version constraints, e.g., OSX >= 10.10.
It also adds enough type checking and SILGen to get the parsing tests to run without triggering "Unimplemented" assertions.
Swift SVN r21865
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
Completely disable the AST transformation for single-expression closures. When
this transformation picks up an incomplete expression, the resulting AST is
almost guaranteed to have type mismatches, and the type checker just marks
everything with error types.
rdar://17193319 rdar://17086137
Swift SVN r20153
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
We were working around this in several different places, which was
error-prone (see <rdar://problem/17479771>). This way, we always have
usable left/right delimiter locations.
Swift SVN r19292
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
Do this by only warning on self-referential uses of a variable when there's
not another binding found in the local scope. This probably still restricts
some reasonable edge cases, but it at least allows shadowing the variable
with a local name.
<rdar://problem/17087232>
Swift SVN r18771
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
This preserves more of source info (e.g. API name location) and simplifies things since
we don't have to construct ParamDecls for the unnamed parameters later on.
Swift SVN r17828
PatternBindingDecls, and inject the vardecls into the name resolution
scope while parsing the body of the closure. This allows references
from the body of the closure to be resolved to the capture list,
e.g. in cases like the testcase.
Swift SVN r17760
leftovers from one of the old selector syntaxes. The general expression
suffix parsing loop handles trailing closures in a superset of the cases
that this code does. NFC.
Swift SVN r17604
much fuzzier, and the real parse is stricter. Also, generalize this
to support the full "unowned name = expr" syntax in the capture list.
There is still a lot missing here.
Swift SVN r17499
