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
This fixes the import of enums like NSCalendarUnit, which changed from
NSXXXCalendarUnit to NSCalendarUnitXXX, as has been the guideline in
recent years. Now even when the old names are present, we can still
prefix-strip based on the new names. If /all/ options are deprecated,
though, we'll prefix-strip as we did before.
Note that we /don't/ check the current deployment target for this,
because we want to use the "nice" names as soon as we have an SDK where
they're available, not when the deployment target matches such an SDK.
rdar://problem/17686122
Swift SVN r26184
This commit suppresses deprecation warnings for references to deprecated symbols
by climbing the DeclContext hierarchy to determine if the warning location is
inside an implicit function.
This is a quick fix to get rid of spurious warnings for deprecated enums whose
nil literal conformance is synthesized by the importer. These warnings would
occur even 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. This quick fix intentionally drops some valid warnings
(for example, for a synthesized call to a deprecated initializer in a super
class). rdar://problem/20024980 tracks adding these special purpose warnings
back.
rdar://problem/20007266
Swift SVN r25720
typedef unsigned long ByteCount;
typedef unsigned long ItemCount;
Both of these are still in use by CoreMIDI, but we don't have a reason to
keep them distinct in Swift.
rdar://problem/19939552
Swift SVN r25529
...even if they were designated in the base class. (Unless they're required,
in which case they're still required.)
This led to Swift subclasses treating convenience initializers as
designated initializers, which (if synthesized) led to properties being
initialized twice.
rdar://problem/19730160
Swift SVN r25410
We certainly can't import them as stored properties, and it's too late to try to bridge them as computed property, so restore the old behavior of importing them as unbridged object types. The types still come in as strong managed reference types, which is still wrong, but seems to be right enough for Khan Academy and potentially other existing apps for now, and I don't want to introduce additional source-breaking changes and instability this late in the game. Fixes rdar://problem/19789023, leaving rdar://problem/19790608 to be done when we can afford more churn.
Swift SVN r25158
...and then fix our forward-declaration logic that assumed that they did.
This fixes a rare case where we would end up printing "enum" twice if the
user (benignly) misused NS_ENUM.
rdar://problem/19769964
Swift SVN r25143
Converging APIs to use ``Int`` as the default integer type allows users to
write fewer explicit type conversions.
Importing ``size_t`` as a signed ``Int`` type is not be a problem for 64-bit
platforms. 32-bit platforms are important, but the usecase for an
unsigned ``size_t`` on 32-bit platforms is pretty marginal, and for code
that nevertheless needs to do that there is always the option of doing a
bitcast to ``UInt`` or using C.
rdar://18949559
Swift SVN r25070
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
