This functionality doesn’t really change what we accept right now, because we eagerly import all of the methods of a class when we do *any* kind of lookup into the class. However, when we manage to stop doing that, this operation will become more important.
Swift SVN r23289
Diagnose cases where the use of @objc will produce Objective-C methods
that end up overriding an Objective-C method in a superclass, when
that override is not properly represented as an override in the Swift
type system. This can happen when the Objective-C methods are produced
by different kinds of entities. For example:
class Super {
@objc var property: Int
}
class Sub : Super {
@objc func setProperty(property: Int) { }
}
In Swift, Sub.setProperty and Super.property are completely
unrelated. However, both produce an Objective-C instance method with
the selector "setProperty:", so we end up with unexpected overriding
behavior. Diagnose this whenever it occurs, regardless of the kind of
@objc entity that produced the Objective-C methods: initializers,
deinitializers, methods, properties, or subscripts.
Implements the rest of the intended functionality of
rdar://problem/18391046, with the caveat that there are two remaining
classes of bugs:
1) Superclasses defined in a module (or imported from a Clang
module) aren't handled properly yet; we might not see those methods.
2) We won't properly detect all of these failures when the methods
are scattered across different source files in the same module.
Swift SVN r23170
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
When performing name lookup for a declaration that is being called,
use the argument labels at the call site to filter out those
declarations with incompatible argument labels.
Swift SVN r22176
Removes the initWithBool: hack from the Clang importer. We can now
express NSNumber's conformance to the BooleanLiteralConvertible
protocol in the overlay.
Swift SVN r21976
Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
Per API review with Ali. While we're here, give the initializer a corresponding 'rawValue' argument label, and change the associated type name to RawValue to match.
Swift SVN r21888
We don't want them showing up in SourceKit's generated interface for a module
(e.g. NSInvocation should not actually appear in the ObjectiveC module).
No tests because swift-ide-test prints implicit decls as well as explicit ones.
Swift SVN r21858
This can be used by SourceKit's interface printer to display modules with
forward declarations of classes in dependent modules, e.g. ObjectiveC
forward-declaring Foundation's NSString for use in NSObject. We can consider
doing something similar for C tag types (structs and enums).
Part of rdar://problem/18273845
Swift SVN r21828
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
This is a hack that allows us to support accessibility APIs in Swift.
It addresses radar://17509751.
A class might conform to both NSAccessibility (containing accessibility
properties) and individual accessibility protocols (containing
accessibility methods with the same names as the properties). This should
not compile (but currently happens to compile). To avoid the problem down
the road, we import setters and getters instead of the accessibility
properties from NSAccessibility.
Swift SVN r21757
Specifically, it should not ever have a clang::TypedefDecl as its Clang node,
even if the RecordDecl is anonymous and immediately wrapped in a typedef.
It looks like no one was ever doing this intentionally; it's just left over
from before we looked through typedefs at all. This is important because we
use the clang::RecordDecl for IRGen layout if it's present; before this patch
we would fall back to Swift layout for these structs (clearly wrong).
The one exception here is enums -- NS_OPTIONS and named C enums get imported
as structs as well. If we add any other exceptions, we should be sure they
are dealt with in IRGen as well.
The change in the printed interface output is due to the source location
for the Clang node of an NS_ENUM or NS_OPTIONS decl being inside a macro.
I didn't see a quick fix for this, so I'm going to ignore it for now.
Swift SVN r21748
When determining whether one imported initializer stomps on another,
use the parameter types rather than the full type. This prevents
differences in failability from causing ambiguities.
Swift SVN r21692
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
Depending on visitation order, we would occasionally leave the factory
method available if we had completely imported the initializer
first. Fixes <rdar://problem/17261609>.
Swift SVN r21361
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
i.e. don't look for attributes on an @class somewhere.
Also do this for tag decls, whose attributes propagate forwards until there's
a definition.
<rdar://problem/17986861>
Swift SVN r21223
Without this, we try to bring these in as CF types, and then ARC tries to
manage them, and the program crashes.
<rdar://problem/17211521>
Swift SVN r21081
This handles things like NSSwapHostLongLongToBig and MKMapRectMake that
are static inline functions that themselves call other static inline
functions.
<rdar://problem/17227237>
Swift SVN r21080
This is a step towards making the framework easier to use in Swift; in the
actual headers, these are typed as "CFTypeRef" or "const CFTypeRef", which
is not considered Hashable (and thus cannot be put in a dictionary).
Unfortunately, CFStringRef is also not hashable, so we're not there yet,
but at least this allows a freer conversion to NSString.
Part of <rdar://problem/17162475>
Swift SVN r20931
This completes <rdar://problem/17024498>, except that we don't yet do
anything with 'deprecated' or 'obsoleted'. The former is covered by
<rdar://problem/17406050>, and I filed <rdar://problem/17873422> for the
latter.
Swift SVN r20845
Nearly all of them come from some annotation written explicitly in the
Objective-C header, and all of them should be shown in the generated
interface for an imported module.
Part of <rdar://problem/17024498>
Swift SVN r20841
