instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
Verify that this bit is set during type-checking on
every ApplyExpr, and fix the remaining locations where
we weren't doing coverage testing on expressions; most
of these were harmless, but it's better to be safe.
Swift SVN r28509
I debated making isBodyThrowing() do this, but decided that
(1) the better recovery mode is to assume that the function
can throw but (2) making isBodyThrowing() return true on an
invalid function would be really weird.
Tested by the crash testsuite.
Swift SVN r27902
a list of their elements, instead of abusing TupleExpr/ParenExpr
to hold them.
This is a more correct representation of what is going on in the
code and produces slightly better diagnostics in obscure cases.
However, the real reason to fix this is that the ParenExpr's that
were being formed were not being installed into the "semantic"
view of the collection expr, not getting type checked correctly,
and led to nonsensical ParenExprs. These non-sensical ParenExprs
blocked turning on AST verification of other ones.
With this fixed, we can finally add AST verification that
IdentityExpr's have sensible types.
Swift SVN r27850
Change how MemberRefExpr and DynamicMemberRefExpr calculate their starting locations so
that even if their base expression is implicit, they will use its starting location if
that location is valid rather than falling back to the start of the name of the member.
Without this change, the Fix-It to suggest wrapping a nested member reference (where the
base is an implicit LoadExpr) in 'if #available(...)' would be inserted in the middle of
the expression.
rdar://problem/20662960
Swift SVN r27799
Now we bind the defer body into a ClosureExpr and emit it at the point of
the defer. At any exit points out of the controlled region, we emit a call
to the closure.
This should cover any problems where expressions cannot be emitted multiple times.
However, this is dramatically more complex than the obvious implementation, so I
hope this patch can be reverted.
Swift SVN r27767
Add syntax "[#Color(...)#]" for object literals, to be used by
Playgrounds for inline color wells etc. The arguments are forwarded to
the relevant constructor (although we will probably change this soon,
since (colorLiteralRed:... blue:... green:... alpha) is kind of
verbose). Add _ColorLiteralConvertible and _ImageLiteralConvertible
protocols, and link them to the new expressions in the type checker.
CSApply replaces the object literal expressions with a call to the
appropriate protocol witness.
Swift SVN r27479
The API review list found it confusing that if #os() and #if os() looked so similar, so
change the availability checking query to be spelled #available:
if #available(iOS >= 9.0, *) {
...
}
Swift SVN r26995
On platforms that are not explicitly mentioned in the #os() guard, this new '*'
availability check generates a version comparison against the minimum deployment target.
This construct, based on feedback from API review, is designed to ease porting
to new platforms. Because new platforms typically branch from
existing platforms, the wildcard allows an API availability check to do the "right"
thing (executing the guarded branch accessing newer APIs) on the new platform without
requiring a modification to every availability guard in the program.
So, if the programmer writes:
if #os(OSX >= 10.10, *) {
. . .
}
and then ports the code to iOS, the body will execute.
We still do compile-time availability checking with '*', so the compiler will
emit errors for references to potentially unavailable symbols in the body when compiled
for iOS.
We require a '*' clause on all #os() guards to force developers to
"future proof" their availability checks against the introduction of new a platform.
Swift SVN r26988
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
If the placeholder is a typed one, parse its type string into a TypeRepr,
resolve it during typechecking and set it as the type for the associated EditorPlaceholderExpr.
Swift SVN r26215
We parse 'try' as if it were a unary operator allowed on an
arbitrary element of an expr-sequence, but sequence-folding
constrains it to never appear on the RHS of most operators.
We do allow it on the RHS of an assignment or conditional
operator, but not if there's anything to the right which
was not parsed within the RHS.
We do this for assignments so that
var x = try whatever
and
x = try whatever
both work as you might expect.
We do this for conditionals because it feels natural to
allow 'try' in the center operand, and then disallowing it
in the right operand feels very strange.
In both case, this works largely because these operators are
assumed to be very low-precedence; there are no standard
operators which would parse outside the RHS. But if you
create one and use 'try' before it, we'll diagnose it.
Swift SVN r26052
Corrected several places where compiler generated AST nodes were not properly
marked as implicit.
For interpolated strings also fixed string segment locations and made sure
the first and last segments are preserved in AST even if they are empty.
Swift SVN r25983
"self." is required whenever it causes a potentially escaping closure to
capture 'self'. This happens not just in plain ClosureExprs, but in local
functions as well. In addition, even no-escape ClosureExprs can require
self to be captured in a /parent/ closure, which may be potentially-escaping.
Swift SVN r25173
This re-applies r24987, reverted in r24990, with a fix for a spuriously-
introduced error: don't use a favored constraint in a disjunction to avoid
applying a fix. (Why not? Because favoring bubbles up, i.e. the
/disjunction/ becomes favored even if the particular branch is eventually
rejected.) This doesn't seem to affect the outcome, though: the other
branch of the disjunction doesn't seem to be tried anyway.
Finishes rdar://problem/19600325
Swift SVN r25054
And even if we don't suggest wrapping in a closure (say, because there's
already a closure involved), emit a more relevant diagnostic anyway.
(Wordsmithing welcome.)
Wrapping a function value in a closure essentially explicitly inserts a
conversion thunk that we should eventually be able to implicitly insert;
that's rdar://problem/19517003.
Part of rdar://problem/19600325
Swift SVN r24987
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
Permit non-Ordinary accesses on references to functions,
with the semantics of devirtualizing the call if the
function is a class member. This is important for
constructing direct call to addressors from synthesized
materializeForSet accessors: for one, it's more
performant, and for another, addressors do not currently
appear in v-tables.
Synthesize trivial accessors for addressed class members.
We weren't doing this at all before, and I'm still not
sure we're doing it right in all cases. This is a mess.
Assorted other fixes. The new addressor kinds seem
to work now.
Swift SVN r24393
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
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
Add the following functionality to the Swift compiler:
* covariant subtyping of Set
* upcasting, downcasting of Set
* automatic bridging between Set and NSSet, including
* NSSet params/return values in ObjC are imported as Set<NSObject>
* Set params/return values in Swift are visible to ObjC as NSSet
<rdar://problem/18853078> Implement Set<T> up and downcasting
Swift SVN r23751
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
We'd like to kill this enum off eventually, since the runtime inevitably needs to be able to handle arbitrary checked casts in opaque contexts, and SILGen and IRGen can deal with picking more optimal runtime entry points for specific casts. Only the container bridging kinds are still depended on anymore, and even those ought to eventually be handlable by the runtime in 'x as T' situations. NFC yet.
Swift SVN r23127
