Most of the time the name importer does a good job deciding whether to
import a particular method as throwing or not. However, when a method
is an override, it skips all that work and assumes the decisions made
for the superclass method apply here as well---which makes sense,
since you're going to get the subclass implementation if you call the
superclass's entry point. This can really throw things off if the
types /don't/ match up, though. Handle the one case where this is
legal according to the rules of Objective-C, and make sure we don't
import methods in the other cases.
rdar://problem/30705461
Actually bridging ObjCBool to Bool is overkill for this, but moreover
it caused problems for non-boolean types that took this code
path. Just go back to the previous logic of unwrapping multiple levels
of struct; this way we can also handle wrappers around integer types
(if we ever have any).
rdar://problem/27985744
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
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
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
