propagate the no-escape bit from a parameter into a closure-expr argument. When a
ClosureExpr is thus inferred to be non-escape, disable the "self." requirement.
.. with fixes. Thanks again to Dmitri for reverting + adding testcase.
Swift SVN r24115
closure-expr argument. When a "
This reverts commit r24085. It causes crashes in the validation
testsuite even with r24094. Testcase:
var x = { f: Int {} }
Swift SVN r24102
This code is trying to avoid emitting multiple diagnostics on the same line:
before it was using a vector to keep track of exprs already emitted, I changed
it to clear the isImplicit() bit. Clearing isImplicit introduces problems
because various things (in this case, SourceRange validation) are keyed off
whether an expression is implicit or not.
Instead of solving it either of those ways, fix our walk to just not recursively
descend into the 'self' argument of a self.foo expression when doing the walk.
While we're here, make it so that ChrisW's example doesn't even produce the
diagnostic in question: the DRE is in a closure, but only because the entire
class is defined in the closure. Stop the walker from descending recursively
into decls at all.
Swift SVN r23793
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
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
This patch adds the ability (-enable-experimental-unavailable-as-optional) to
treat potentially unavailable declarations as if they had optional types. For
the moment, this is only implemented for global variables.
The high-level approach is to (1) record the potential unavailability of a
declaration reference in the overload choice during constraint generation; (2)
treat the declaration as if it had an optional type during overload resolution
(this is similar to how optional protocol members are treated); and (3) add an
implicit conversion (UnavailableToOptionalExpr) during constraint application
to represent the run-time availability check and optional injection.
This patch does not implement SILGen for UnavailableToOptionalExpr.
Swift SVN r22245
This commit adds a new expression (AvailabilityQueryExpr) and a single kind of
specification for when a block of code or function is available
(VersionConstraintAvailabilitySpec). We may add more kinds of specifications
in the future. At the moment, the AvailabilityQueryExpr allows only a
single platform to be queried; I will add support for multiple platforms
in a later commit.
This commit contains just the added AST nodes; no parsing, type checking, etc.
I’ve added assert(false && “Unimplemented”) for places where support for
AvailabilityQueryExpr will need to be added later.
Swift SVN r21760
This includes proper printing support as well as proper platform checking
when seeing if a decl is unavailable. A few other places in the code will
now use AvailabilityAttr::isUnavailable instead of just checking the
is-unavailable-always flag (and not always checking the platform).
No new tests yet because this doesn't include /parsing/ the other fields
of AvailabilityAttr. That will come next, at which point we'll test each
of the cases that has been switched over to use
AvailabilityAttr::isUnavailable.
Part of <rdar://problem/17024498>
Swift SVN r20844
Previously, we were just storing setter accessibility via the accessibility
level on the setter function. However, some Stored properties never actually
have a setter synthesized, which led to the compiler dropping the setter
accessibility at serialization time. Rather than try to hack up something
clever, just store the setter accessibility explicitly in every
AbstractStorageDecl. (We still only serialize it for VarDecls, because
settable SubscriptDecls always have setter functions.)
<rdar://problem/17816530>
Swift SVN r20598
to emit fixit's when we rename something, e.g.:
t.swift:6:9: error: 'float' has been renamed to Float
var y : float
^~~~~
Float
Adopt this in the stdlib.
Swift SVN r20549
There's no meaningful way in which these methods are public, since they
can't be accessed through any value of the type
<rdar://problem/17647878>
Swift SVN r20224
...unless they are in a private class.
Consider this scenario:
class Base {
func foo() -> Base { ... }
}
class Sub : Base {
private override func foo() -> Sub { ... }
}
class Grandchild : Sub {
override func foo() -> Base { ... }
}
Because Grandchild can't see Sub, its override of foo() looks perfectly
reasonable...but now Sub's expectations for foo() have been broken.
Swift SVN r19769
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
We no longer need this language feature. The Sema support is still skeletally kept in place because removing it seems to totally break pointer conversions; I need to work with Joe and Doug to figure out why that's the case.
Swift SVN r19289
Add primitive type-checker rules for pointer arguments. An UnsafePointer argument accepts:
- an UnsafePointer value of matching element type, or of any type if the argument is UnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is UnsafePointer<Void>, or
- an inout Array parameter of matching element type, or of any type if the argument is UnsafePointer<Void>.
A ConstUnsafePointer argument accepts:
- an UnsafePointer, ConstUnsafePointer, or AutoreleasingUnsafePointer value of matching element type, or of any type if the argument is ConstUnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>, or
- an inout or non-inout Array parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>.
An AutoreleasingUnsafePointer argument accepts:
- an AutoreleasingUnsafePointer value of matching element type, or
- an inout parameter of matching element type.
This disrupts some error messages in unrelated tests, which is tracked by <rdar://problem/17380520>.
Swift SVN r19008
This means that we'll get deferred checking of array and dictionary
downcasts when writing "arr as Derived[]",
"(dict as? Dictionary<DerivedKey, DerivedValue>)!", etc, when the
collection can do so.
This is both a general optimization and also staging for
<rdar://problem/17319154>.
Swift SVN r18975
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
Semantically, these expressions handle the same thing: an upcast of a
collection when the underlying element types of the source are
subtypes of or can be bridged to subtypes of the destination. This
reduces some branching in the type checker and eliminates duplication
in SILGen.
Swift SVN r18865
Allow class metatypes (including class-constrained existential metatypes) to be treated as subtypes of AnyObject, and single-@objc protocol metatypes to be treated as subtypes of the Protocol class from objc. No codegen support yet, so this is hidden behind a frontend flag for now.
Swift SVN r18810
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
Array downcast is an explicit cast written "x as U[]", not an implicit
conversion, so make it a subclass of ExplicitCastExpr. The only
effective change here is that we retain the location of the "as" and
the type as written in the AST. No semantic change.
Swift SVN r18391
We weren't diagnosing initializer delegation/chaining, subscripts, or
(the one that got me concerned) members accessed through AnyObject.
Swift SVN r18271
<rdar://problem/16264989> property not mutable in closure inside of its willSet
and:
<rdar://problem/16826319> willSet immutability behavior is incorrect
by changing how we handle immutability of an observing property within its willSet.
Instead of trying to model it as an rvalue, just model it as an lvalue (which it is)
and diagnose the problem with a warning in MiscDiagnostics.
Swift SVN r18184
- Continue adding support for checked downcasts of array types (rdar://problem/16535104)
- Fix non-bridged array conversions post-r17868
- Fix rdar://problem/16773693
- Add tests for NSArray coercions to and from Array<T>
Swift SVN r17957
