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
Add a new convention to describe what happens with
nonzero_result on a type that isn't imported as Bool.
This isn't really a safe convention to implement, but
calls are fine.
Implements <rdar://21715350>.
Swift SVN r29953
If there is a method -foo: that's unavailable (for whatever reason), and we now
have a method -foo:error: that we'd like to import, it's okay to drop the error
parameter there. Overload resolution can handle filtering out the unavailable
method.
rdar://problem/21497221
Swift SVN r29746
If the common prefix of the enum /elements/ had an underscore in the /middle/,
we previously had cases where we'd end up leaving that underscore in place.
rdar://problem/20800204
Swift SVN r29673
We wouldn't care except that its constants are named TRUE and FALSE and
that shows up in the global namespace.
rdar://problem/20943410
Swift SVN r29651
Share the code that does elementwise coercions, which already behaved correctly, with the code that does struct-to-struct coercions, which still had the overly-conservative constraint. Fixes rdar://problem/21294916.
Swift SVN r29399
...so that their modern NSError-based variants won't be imported using an
extra "error: ()" parameter. Apart from looking prettier, this avoids a
crash when overriding the "error: ()" versions, rdar://problem/21144509.
Once NS_REFINED_IN_SWIFT has been implemented we can probably use that instead.
Filed rdar://problem/21192039 to remove the hack at that point.
rdar://problem/21177341
Swift SVN r29212
NS_SWIFT_NAME on enum constants has two effects: on top of renaming the
member, it also removes it from the prefix-matching logic.
Part of rdar://problem/19240897
Swift SVN r28927
Then use that to ban NSError.init(), because it doesn't create a valid
NSError. In the long run Foundation will hopefully add this to their
headers, but they can't yet (rdar://problem/19977891).
rdar://problem/21042412
Swift SVN r28881
Reapply r28734. Argyrios updated SourceKit dependencies on swift and clang libraries in
SourceKit r28765, so this should work now.
Change the AST printer to use the new short-form @available attribute syntax for
attributes with only introduction versions. So, for example, a declaration
annotated as:
@available(iOS, introduced=8.0) @available(OSX, introduced=10.10)
func foo()
will be printed as:
@available(iOS 8.0, OSX 10.10, *) func foo()
We won't include the attribute on the short form if it has a deprecated or
obsoleted version; nor if it has a message, a rename, or marks unconditional
unavailability.
This commit has a corresponding change to the SourceKit tests.
rdar://problem/20982322
Swift SVN r28768
Change the AST printer to use the new short-form @available attribute syntax for
attributes with only introduction versions. So, for example, a declaration
annotated as:
@available(iOS, introduced=8.0)
@available(OSX, introduced=10.10)
func foo()
will be printed as:
@available(iOS 8.0, OSX 10.10, *)
func foo()
We won't include the attribute on the short form if it has a deprecated or
obsoleted version; nor if it has a message, a rename, or marks unconditional
unavailability.
There is a corresponding change to the SourceKit tests.
rdar://problem/20982322
Swift SVN r28734
For some reason this was only breaking with initializers, and not
ordinary methods, where there was both a throwing and non-throwing
version of the same method.
Fixes <rdar://problem/20922973>.
Swift SVN r28534
...so that they can still be used with exhaustive switches.
This is a hack---groveling through the AST to see if it's in the particular
form of an imported enum case alias---but at least it's limited to imported
properties.
More rdar://problem/18662118
Swift SVN r28326
It's possible (and likely!) that Objective-C method conflicts will
involve declarations with and without source locations. Make sure that
the first error has a property source location in such cases. Fixes
rdar://problem/20042769.
Swift SVN r28299
With the test case included in this commit we were first hitting an
assert due to a cast<FuncDecl>(decl) that failed because the supplied
decl was for a constructor, and after fixing this we failed verification
due to using the wrong result type for the generated thunk.
The result should have the same kind of 'optionalness' as the base-class
method's result, but if the type is some kind of optional it should be
wrapping the same type as the thunked-to function.
Fixes at least part of rdar://problem/20663080. I need to go back and
patch an older toolset to see if this completely resolves the issue.
Swift SVN r28289
preserve the original method name.
This heuristic is based on the Objective-C selector and therefore
doesn't really handle factory methods that would conflict with
initializers, but we can hope that those simply don't come up in
the wild.
It's not clear that this is the best thing to do --- it tends to
promote the non-throwing API over what's probably a newer, throwing
API --- but it's significantly easier, and it unblocks code without
creating deployment problems.
Swift SVN r28066
results when finding bridged types, rather than reinventing
(well, pre-inventing) the same thing elsewhere.
Doing this apparently forces AbstractionPattern to deal
with ObjC protocol methods for the first time, which are
generic and therefore require even the Clang-based
abstraction patterns to propagate generic signatures.
Use this infrastructure to allow foreign error conventions
to suppress the wrapping of nonnull bridged collection results
in a level of optionality. We can't treat nil results as
an empty collection while simultaneously treating them as
an error signal.
Swift SVN r28022
@warn_unused_result can be attached to function declarations to
produce a warning if the function is called but its result is not
used. It has two optional parameters that can be placed in
parentheses:
message="some message": a message to include with the warning.
mutable_variant="somedecl": the name of the mutable variant of the
method that should be suggested when the subject method is called on
a mutable value.
The specific use we're implementing this for now is for the mutating
and in-place operations. For example:
@warn_unused_result(mutable_variant="sortInPlace") func sort() -> [Generator.Element] { ... }
mutating func sortInPlace() { ... }
Translate Clang's __attribute__((warn_unused_result)) into
@warn_unused_result.
Implements rdar://problem/18165189.
Swift SVN r28019
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
When -enable-simd-import is active, if we encounter a vector type, try to load the SIMD Swift module, and if successful, map float, double, and int vectors to SIMD.{Float,Double,Int}N types if they exist.
Swift SVN r27367
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
This is the new and improved version of
__attribute__((annotate("swift1_unavailable"))), with the "improved" being
specifically that the 'availability' attribute supports a message.
This requires a corresponding Clang commit.
Swift side of rdar://problem/18768673.
Swift SVN r27053
When synthesizing a designated initializer override, we now ensure that the synthesized
initializer has the same availability as the initializer it is overriding.
Swift SVN r26732
This commit suppresses errors for references to unavailable symbols inside
implicit functions.
This is a quick hack to fix a hit-listed radar <rdar://problem/20007266> where
the compiler was emitting spurious errors for enums explicitly marked
unavailable in Objective-C and whose nil literal conformance is synthesized by
the importer. These errors could occur when user code made no apparent reference
to the enum in question and instead only referred to an imported class that
itself referred to the enum in a method signature.
We will need to do something systematic about availability and deprecation
diagnostics in synthesized code. In particular, we should make sure that:
(1) we never emit code that references explicitly unavailable symbols;
(2) that the user never gets an error about symbol that they did not explicitly type; and
(3) that errors can dealt with via the appropriate availability check or annotation. I'm
tracking this with radar rdar://problem/20024980.
rdar://problem/20007266
Swift SVN r26251
When an imported Objective-C property has nullability, force that
nullability onto the result of its getter and the parameter of its
setter, so that we have consisteny nullability among the three. SILGen
assumes that this is the case, so this fixes the null_resettable-based
crash in <rdar://problem/20145910>.
Swift SVN r26198
