Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
When adding mirror declaration members to a class, if the protocol has an annotated
availability then apply that availability to the mirror declaration member unless the
protocol member already has its own availability.
rdar://problem/21825141
Swift SVN r30251
The importer conjures up "mirrored" member declarations for imported
Obj-C classes that conform to a protocol with members that aren't exposed
in public headers. This commit extends our existing inference of availability
for members of unannotated Obj-C protocols to cover mirrored declarations
as well. For these mirrored declarations, we additionally constrain the
inferred availability with the availability of the class itself.
Swift SVN r30244
Based on feedback from Jordan, update r30060 to synthesize availability
attributes on unannotated Obj-C protocols in the importer. This has a
user-visible effect: calls to protocol requirements with these synthesized
attributes will now cause an availability error if the requirement is not
available in the calling type refinement context.
Swift SVN r30096
There have been several cases in the SDK where an Objective-C class is annotated
with availability but a related protocol is missing annotations. If this protocol refers
to the class in a requirement than it will be impossible for a Swift type to conform
to the protocol.
One such example the SFSafariViewControllerDelegate protocol:
protocol SFSafariViewControllerDelegate {
func safariViewControllerDidFinish(controller: SFSafariViewController)
}
@available(iOS 9.0, *)
class SFSafariViewController { }
Suppose the user then has a class that she wants to deploy back to iOS 8.0 and
yet still conform to SFSafariViewControllerDelegate so she can use SFSafariViewController
on iOS 9.0 and above:
@available(iOS 8.0, *)
class MyViewController : SFSafariViewControllerDelegate {
@available(iOS 9.0, *)
func safariViewControllerDidFinish(controller: SFSafariViewController) { }
}
Here the user faces a catch-22: she must mark her witness for
safariViewControllerDidFinish() as @available(iOS 9.0, *) -- otherwise availability
checking will complain that SFSafariViewController is not available. But if she does so,
the checker will complain that MyViewController does not conform to
SFSafariViewControllerDelegate because the protocol requires the witness to always be
available.
This commit adds a little bit of availability inference to protocol conformance
checking to solve this problem. When checking Objective-C protocol conformance, it
infers the required availability of protocol requirements by looking at the
availabilities of the return and parameter types. This is a very targeted inference:
it is only used for protocol conformance for Obj-C protocols and it is limited
to where neither the protocol nor the protocol requirement has availability markup. This
inference can only ever make more the checker more lenient -- it will never
cause programs that previously passed checking to fail it.
Swift SVN r30060
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
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
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
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
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
Remove the suppression of deprecation and potential unavailability diagnostics in
synthesized functions. We still suppress some explicit unavailability diagnostics -- those
in synthesized functions in synthesized functions that are lexically contained in
declarations that are themselves annotated as unavailable. For these cases, the right
solution <rdar://problem/20491640> is to not synthesize the bodies of these functions in
the first place.
rdar://problem/20024980
Swift SVN r27203
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
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
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
This commit changes the clang importer to always import attributes on property accessors.
Previously, attributes were only imported if the accessor method was declared before the
property but not if the accessor method was declared after it.
Swift SVN r25018
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
