This changes the diagnostic text when a variable cannot be marked potentially unavailable
so that it does not explicitly use the long-style form of @available:
It changes:
"stored properties cannot be marked potentially unavailable with 'introduced='"
to:
"stored properties cannot be marked potentially unavailable with '@available'"
Swift SVN r30446
We were skipping building refinement contexts for function declarations without bodies
(such as protocol requirements and @asmname functions). These contexts are needed to
determine whether parameter and return types are available in those declaration.
Swift SVN r30380
It is safe to add an @available attribute to lazy properties, so suggest a
Fix-It to do so if the property references a potentially unavailable symbol.
rdar://problem/20968204
Swift SVN r30321
Update the diagnostic emitted when an accessor override is less available than the
declaration it overrides to mention the accessor kind and the name of the property rather
than just the accessor declaration name, which is '_'.
rdar://problem/20427938
Swift SVN r30319
Now that we allow types to conform to protocols that are less available than the
type itself, we should consider the availability of the protocol when
determining whether a witness is sufficiently available to satisfy the protocol
requirement.
In particular, we should allow the following:
@available(iOS 9.0, *)
class UIRefrigerator { }
@available(iOS 9.0, *)
protocol UIRefrigeratorDelegate {
func refrigeratorDidCool(refrigerator: UIRefrigerator)
}
@available(iOS 7.0, *)
class MyViewController : UIViewController, UIRefrigeratorDelegate {
@available(iOS 9.0, *)
func refrigeratorDidCool(refrigerator: UIRefrigerator) {
...
}
}
This is safe because MyViewController's refrigeratorDidCool() witness is
available everywhere the protocol is available. To check this, we now
additionally intersect the availability of the protocol with the availabilities
of the witness and the requirement before checking containment.
Swift SVN r29996
The previous rules for availability checking prevented types from conforming to protocols
that were less available than the type itself. This was too restrictive, because we want
to allow developers to add additional behavior to their existing classes to
conform to new protocols while still employing older functionality from those classes on
older OSes:
@available(iOS 9.0, *)
protocol UIRefrigeratorDelegate { }
@available(iOS 8.0, *)
class MyViewController : UIViewController, UIRefrigeratorDelegate { }
We now support this idiom (and adding conformnces via protocol extensions) by allowing
references to potentially unavailable protocols inside inheritance clauses.
It is still an availability error to refer to potentially unavailable protocols in other
settings -- so, for example, attempting to cast to an unavailable protocol will cause
a compile-time error.
rdar://problem/21718497
Swift SVN r29958
Change the fix-it suggesting adding #available to be consistent with the fix-it
adding @available.
This changes "guard with version check" to "add if #available version check".
rdar://problem/21275857
Swift SVN r29648
As Jordan notes, this uses the wrong check: isScriptMode() is also true for
main.swift in an app or command-line tool.
This reverts commit 8a72f4357bc04a386cf82acd1de06896515ab5a8.
Swift SVN r29583
We normally report a warning when a #available() check will always be true
because of the minimum deployment target. These warnings are potentially
annoying when the developer either cannot change the minimum deployment target
from the default (as in playgrounds) or when doing so is burdensome (as for
command-line scripts, which would require passing a target triple) -- so
suppress them.
rdar://problem/21324005
Swift SVN r29582
This prevents us from seeing a less useful error message from SILGen
further down the line.
Also fix a bug where @objc without importing Foundation was not diagnosed
after the first top-level form. Some tests were relying on this behavior,
so fix those tests, either by splitting off the objc parts of the test, or
just by passing the -disable-objc-attr-requires-foundation-module flag.
Fixes <rdar://problem/20660270>.
Swift SVN r29359
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
Instead of the rather inscrutable "'foo()' is less available than protocol requires" be
more helpful: "protocol 'HasFoo' requires 'foo()' to be available on OS X 10.9 and newer".
Also add a note indicating where the conformance was introduced, as this may be in a
separate location from both the witness and requirement.
rdar://problem/20610411
Swift SVN r29028
The type refinement context builder now handles the case where multiple refinement
contexts have scopes ending after the same statement. This fixes a crash when we had
two guard #available()s in the same block.
rdar://problem/21012706
Swift SVN r28763
Allow availability attributes of the form:
@available(iOS 8.0, OSX 10.10, *)
func foo() { }
This form is intended for use by third-party developers when annotating their
own declarations and uses the same syntax as #available(). This annotation
says that on iOS foo() is available on version 8.0 and newer; on OSX it is
available on 10.10; and on any other un-mentioned platform it considered
available on the minimum deployment target and greater. Just like with
For now, we support this form during parsing by synthesizing multiple implicit
long-form @available attributes. So, for example, the above annotation will
synthesize two implicit attributes:
@available(iOS, introduced=8.0)
@available(OSX, introduced=10.10)
func foo() { }
Synthesizing attributes in this way is not ideal -- it makes for a poor Fix-It
experience, among other things -- but it exposes the short-form syntax with
minimal invasiveness.
rdar://problem/20938565
Swift SVN r28647
In anticipation of adding short-form @available() annotations, move validation
of #available() platform/version lists out of Sema and into the parser. This
also enables slightly more graceful recovery from errors.
Swift SVN r28637
This allows #available() to be used in the guard condition of a while loop:
while i > 10, #available(iOS 8.0, *) {
// Use APIs available on iOS 8.0 and above.
}
rdar://problem/20936160
Swift SVN r28623
Stop suggesting Fix-Its to add @available() to stored properties. We don't allow this
yet, so the "fixed" code would still emit an error when compiled.
rdar://problem/20939804
Swift SVN r28604
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
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
We now introduce a TypeRefinementContext for the fallthrough branch of a require/else
statement that continues until the end of the BraceStmt that contains the RequireStmt. The
body of the else is checked in the context that contains the RequireStmt.
This enables availability checking with early return:
require #available(iOS 8.0, *) else { return }
Swift SVN r28113
Loosen restrictions on where #available() can appear in IfStmt guards and refine the
context for guard StmtConditionElements following an availability check.
This enables #available() to be combined with if let optional binding:
if #available(iOS 8.0, *),
let x = someIOS8API() {
// Do more iOS 8 stuff
}
and
if let x = someIOS7API() where #available(iOS 8.0, *),
let y = someIOS8API() {
// Do more iOS 8 stuff
}
Swift SVN r28096
Change the syntax of availability queries from #available(iOS >= 8.0, OSX >= 10.10, *) to
This change reflects the fact that now that we spell the query '#available()' rather than
'#os()', the specification is about availability of the APIs introduced in a particular OS
release rather than an explicit range of OS versions on which the developer expects the
code to run.
There is a Fix-It to remove '>=' to ease adopting the new syntax.
Swift SVN r28025
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
To be safe, protocol witnesses need to be as available as their requirements.
Otherwise, the programmer could access an unavailable declaration by upcasting
to the protocol type and accessing the declaration via its requirement.
Prior to this commit, we enforced safety by requiring that the annotated
available range of a requirement must be completely contained within the
annotated available range of the witness.
However, there are cases where this requirement is too restrictive. Suppose
there is some super class Super with an availability-restricted method f():
class Super {
@availability(iOS, introduced=6.0)
void func f() { ... }
}
Further, suppose there is a protocol HasF with unrestricted availability:
protocol HasF {
void func f()
}
and then a limited-availability class Sub extends Super and declares a
conformance to HasF:
@availability(iOS, introduced=8.0)
class Sub: Super, HasF {
}
Sub does conform to HasF: the witness for HasF's f() requirement is Super's f().
But Super's f() is less available (iOS 6 and up) than HasF's f() requires
(all versions) and so--prior to this commit--the compiler would emit
an error.
This error is too conservative. The conforming type, Sub,
is only available on iOS 8.0 and later. And, given an environment of iOS 8.0
and later, the availability of the requirement and the witness is the same, so
the conformance is safe.
This false alarm arises in UIKit, where Super is UIView, HasF
is UIGestureRecognizerDelegate, and f() is gestureRecognizerShouldBegin().
The fix is to change the safety requirement for protocol witnesses:
we now require that the intersection of the availabilities of the conforming
type and the protocol requirement is fully contained in the intersection of the
availabilities of the conforming type and the witness. It does not matter if
the containment does not hold for versions on which the conforming type is not
available.
rdar://problem/20693144
Swift SVN r27712
Update the Fix-It thats suggests adding a #available() check to include the
wildcard query '*', which is now required. We were omitting it before, which
meant that after applying this Fix-It the developer would get a second Fix-It
to add the '*'.
rdar://problem/20601569
Swift SVN r27514
Suppress API availability diagnostics about protocol conformances when the
-disable-availability-checking frontend flag is passed. We weren't
checking the flag before, so there was no way to disable this diagnostic.
I've added a test to make sure this flag is honored. We can remove the test when
we remove the flag, which is temporary.
Swift SVN r27439
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
Make sure that a witness declaration is at least as available as
the protocol requirement declaration. This is analogous to requiring that an
override is at least as available as the base declaration.
We don’t use the RequirementMatch machinery to mark a candidate as unsafe but
rather let the witness be chosen and then diagnose for potential unavailability.
That is, potential unavailability will not affect the search for a candidate
witness to a requirement. This is less expressive (users cannot write a protocol
that selects an available implementation) but is more predictable.
Swift SVN r27256
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
This is the same as the reverted r27216 except that it does not suggest a FixIt
to make the property lazy.
Swift SVN r27223
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
We can safely support potential unavailability on lazily initialized
properties (and statics), so suggest a Fix-It that adds a lazy attribute when
the property declaration allows for it.
Swift SVN r27216
In source files that are in script mode, global variable initialization
expressions are eagerly executed. For this reason, disallow @availability
attributes having 'introduced=' on script-mode globals.
I had to rejigger a fair number of potential unavailability tests because they
weren't written with this distinction in mind.
Swift SVN r27137
Synthesize implicit @availability attributes to make sure that a synthesized
materializeForSet accessor is available enough to access the underlying storage and its
getter and setter.
These synthesized attributes could trigger redundant diagnostics when a subclass gives
overriding getters or setters non-contravariant availability. We detect when this
happens and suppress the redundant diagnostics.
This commit also improves availability diagnostics in synthesized code. We now respect
synthesized @availability annotations on containing DeclContexts when determining the
potential OS versions that could be executed at invalid SourceLocations.
Swift SVN r27002
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
Change availability Fix-It notes to use a DescriptiveDeclKind so that the notes are
more precise in their description of where an availability attribute will be added.
So, for example, the note will now say "add @availability attribute to enclosing class"
instead of "add @availability attribute to enclosing type".
In these Fix-Its, I have special-cased the descriptive kind for PatternBindingDecls to
instead use the description for an associated VarDecl to avoid describing property
declarations as "pattern bindings" to the user.
Swift SVN r26420
The commit fixes availability Fix-Its on enum elements to suggest a new availability
attribute on the enum case (which is where attributes live in concrete syntax) rather than
on the enum element (which is where they are attached in the abstract syntax tree).
Swift SVN r26401
Minor tweaks to availability diagnostic text based on feedback from Chris, Ted, and Doug.
This changees "'foo' is only available on OS X version 10.10 or greater" to
"'foo' is only available on OS X 10.10 or newer".
This change also updates the deprecation and obsoleted diagnostics to be consistent with
the new text.
Swift SVN r26344
We now suggest up to three Fix-Its for each reference to a potentially
unavailable symbol: one to wrap the reference in an if #os(...) { ... }
guard (if possible), one to add an @availability attribute to an enclosing
property or method (if possible), and one to add an @availability attribute
to an enclosing class/struct/extension, etc. or global function.
The goal here is not to infer the "best" Fix-It but rather to ensure
discoverability of #os() and @availability attributes. We want the user, when
faced with an availability diagnostic, to be aware of the tools in her toolbox
to deal with it.
This is still missing QoI improvements, including Fix-Its to update
existing @availability attributes and more precise wording in diagnostics
(e.g, "initializer" instead of function, "class" instead of "type"). These
improvements will come in later commits.
Swift SVN r26073
At Jordan's request, add a test to ensure that we emit an error when a declaration
inside an extension is more available than the extension itself. Also change a
getContextKind() comparison + cast<> to a dyn_cast<>.
Swift SVN r25592
This commit allows @availability attributes on extensions.
Unlike other declarations, extensions can be used without referring to them
by name (they don't have one) in the source. For this reason, when checking
the available version range of a declaration we also need to check to see if it is
immediately contained in an extension and use the extension's availability if
the declaration does not have an explicit @availability attribute itself.
This commit also moves building the primary file type refinement context hierarchy
in performTypeChecking() to before we resolve extensions. Resolving extensions checks for
availability of the extended declaration, so the TRC for the extension must be constructed
before then.
Swift SVN r25589
This commit removes an unnecessary check that ensured that inferred type
parameter actuals are available. This check is unnecessary because the
declaration for any inferred actual type parameter (i.e., a generic type
argument at the callsite) must be referred to in an enclosing type refinement
context. If the inferred type is not available, this reference will cause a
diagnostic to be emitted, so we don't need to emit another diagnostic for the
inferred actual. Further, this diagnostic was potentially confusing because the
point at which we emitted the diagnostic did not directly mention the type
name (because it was inferred).
This commit also beefs up testing of diagnostics for potentially unavailable
type parameters.
Swift SVN r25540
This commit validates @availability() attribute version ranges to ensure that
a declaration is not more available than its lexically containing scope. To do so,
we find the inner-most declaration containing an @availability attribute that itself
has an @availability attribute and check that first attribute's available
version range is contained in the enclosing declaration's available range. If not,
we emit a diagnostic.
This commit removes a FIXME for checking @availability and overrides. It appears that
the FIXME is a copy/paste to/from AttributeOverrideChecker, where it still resides.
Swift SVN r25453
With this commit, availability attributes can now be placed on enum elements. We
emit an error (protected by the -enable-experimental-availability-checking flag) for
references to potentially unavailable enum cases. We do *not* emit an error when the
programmer pattern matches (i.e., with switch) on a potentially unavailable case.
This commit does not import availability attributes from clang. I will add support for
this in a later commit.
Swift SVN r24929
This commit adds checking for accesses of potentially unavailable getters and setters.
When walking an expression to check availability, AvailabilityWalker now keeps track of
the context for when it encounters a MemberRefExpr. This context be either
(1) the next encountered member reference could cause the member's getter to be called
(e.g., the member ref is for a read of the property); (2) the member's setter could be
called (e.g., the member ref is the left-hand-side of an assignment); or (3) the member
ref generates the lvalue for for an InOutExpr (&) -- in which case we have to assume both
the getter and the setter could be called. These diagnostics are protected by the
-enable-experimental-availability-checking flag.
This commit does not import separate getter and setter availability from Objective-C; that
is coming in a future commit.
Swift SVN r24870
