Upstream cfe change r284797 adds explicit handling for modules
named Darwin, and requires that it not depend on modules which
it does not parent. Because ctypes is a peer module of Darwin,
this means that Darwin must no longer depend on ctypes.
This can be avoided by duplicating some integral definitions
in MacTypes.h, and by adding extra imports to a few tests.
When a parameter has distinct "nil" and "empty" values, "nil"
generally represents the default settings, while "empty" is
explicitly cleared.
rdar://problem/27196867
The unavailable-in-current-Swift declarations introduced by the Clang
importer to help with migrating Swift 2.x code to Swift 3's naming
cause problems with unqualified name lookup when they shadow, e.g.,
types. The biggest problem in practice is with "URL", which is a
common Cocoa property name (in Swift 2) that becomes "url" in Swift 3,
but the old name conflicts with the Foundation value type "URL".
Fixes <rdar://problem/26236989>.
Both option set (CF_OPTIONS/NS_OPTIONS) and NSDictionary parameters
tend to be used as option sets. The former already get a default
argument of []. This commit adds a default argument of [:] for the
latter, identified by a parameter whose argument label involves
"options", "attributes", or "userInfo".
The properties of a context indicate those things that are considered
"contained within" the context (among other things). This helps us
avoid producing overly-generic names when we identify a redundancy in
the base name. For example, NSView contains the following:
var gestureRecognizers: [NSGestureRecognizer]
func addGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
func removeGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
Normally, omit-needless-words would prune the two method names down to
"add" and "remove", respectively, because they restate type
information. However, this pruning is not ideal, because a view isn't
primarily a collection of gesture recognizers.
Use the presence of the property "gestureRecognizers" to indicate that
we should not strip "gestureRecognizer" or "gestureRecognizers" from
the base names of methods within that class (or its subclasses).
Note that there is more work to do here to properly deal with API
evolution: a newly-added property shouldn't have any effect on
existing APIs. We should use availability information here, and only
consider properties introduced no later than the entity under
consideration.
Typedefs provide weak type information in both C and Swift, so don't
use the names of typedefs when omitting needless words. This improves
a number of APIs where it looked like the words were redundant, but
the type system was deceiving us. For example:
- func setHolding(_: NSLayoutPriority, forSubviewAt: Int)
+ func setHoldingPriority(_: NSLayoutPriority, forSubviewAt: Int)
Swift SVN r32449
When the first parameter of a function has Boolean type, try to create
an argument label for it. We start with the (normally non-API)
parameter name as the argument label, then try to match that against
the end of the base name of the method to eliminate redundancy. Add a
little magic, and here are some diffs:
- func openUntitledDocumentAndDisplay(_: Bool) throws -> NSDocument
+ func openUntitledDocument(display _: Bool) throws -> NSDocument
- func fontMenu(_: Bool) -> NSMenu?
- func fontPanel(_: Bool) -> NSFontPanel?
+ func fontMenu(create _: Bool) -> NSMenu?
+ func fontPanel(create _: Bool) -> NSFontPanel?
- func lockFocusFlipped(_: Bool)
+ func lockFocus(flipped _: Bool)
- func rectForSearchTextWhenCentered(_: Bool) -> NSRect
+ func rectForSearchText(whenCentered _: Bool) -> NSRect
- func dismissPreviewAnimated(_: Bool)
- func dismissMenuAnimated(_: Bool)
+ func dismissPreview(animated _: Bool)
+ func dismissMenu(animated _: Bool)
Swift SVN r32392
Beyond the first parameter, the "with" or "using" at the beginning of
an argument label is needless, because one does not read the base name
of the method as if it distributed to the parameters. Some examples:
- func setProperty(_: String, withValue: AnyObject? = nil)
+ func setProperty(_: String, value: AnyObject? = nil)
- func hitTest(_: NSRect, withImageDestinationRect: NSRect, context:
NSGraphicsContext? = nil, hints: [String : AnyObject]? = nil,
flipped: Bool) -> Bool
+ func hitTest(_: NSRect, imageDestinationRect: NSRect, context:
NSGraphicsContext? = nil, hints: [String : AnyObject]? = nil,
flipped: Bool) -> Bool
- func track(_: NSRulerMarker, withMouseEvent: NSEvent) -> Bool
+ func track(_: NSRulerMarker, mouseEvent: NSEvent) -> Bool
Swift SVN r32141
It's a cleaner rule to specify that we omit needless words from the
base name of a method and *then* split it for default arguments. This
tweak actually caught a small number of cases where we weren't
splitting properly, but should have.
Swift SVN r32133
When the context type of a declaraton matches the result type,
strip off redundant type information at the beginning of the
declaration name if it is followed by a preposition. This covers the
class of transformations on performs on a class that produce a value
of the same type as that class, e.g., NSURL's "URLWithHTTPS" or
NSString's "stringByAppendingString".
When that preposition is the magical "By" and is followed by a gerund,
strip the "By" as well. Note that this is slightly more conservative
now for methods, which previously stripped based on the result type
(always). For example, in NSCalendar:
- func adding(_: NSDateComponents, to: NSDate, options:
NSCalendarOptions = [])
-> NSDate?
+ func dateByAdding(_: NSDateComponents, to: NSDate, options:
NSCalendarOptions
= []) -> NSDate?
but it's more general for properties, e.g.,
- @NSCopying var bezierPathByFlattening: NSBezierPath { get }
- @NSCopying var bezierPathByReversing: NSBezierPath { get }
+ @NSCopying var byFlattening: NSBezierPath { get }
+ @NSCopying var reversing: NSBezierPath { get }
The important part is that the rules are more uniform and the code is
more regularly structured: we strip this leading type information when
it's redundant with the context and result type, regardless of whether
we have a property or a method, and the "By" rule is no longer special
in that regard.
Swift SVN r32129
This takes an highly-redundant API name like NSBezierPath's
func bezierPathByReversingPath() -> NSBezierPath
and turns it into
func reversing() -> NSBezierPath
Also, handle 'instancetype' properly when omitting words matching the
result type from the front of the base name.
Swift SVN r32119
My temporary hackery around inferring default arguments from imported
APIs was too horrible. Make it slightly more sane by:
1) Actually marking these as default arguments in the type system,
rather than doing everything outside of the type system. This is a
step closer to what we would really do, if we go in this
direction. Put it behind the new -frontend flag
-enable-infer-default-arguments.
2) Only inferring a default argument from option sets and from
explicitly "nullable" parameters, as stated in the (Objective-)C API
or API notes. This eliminates a pile of spurious, non-sensical "=
nil"'s in the resulting output.
Note that there is one ugly tweak to the overloading rules to prefer
declarations with fewer defaulted arguments. This is a bad
implementation of what is probably a reasonable rule (prefer to bind
fewer default arguments), which intentionally only kicks in when we're
dealing with imported APIs that have default arguments.
Swift SVN r32078
For cases where the Clang importer provides a defaulted argument,
e.g., "[]" for option sets and "nil" for optionals, remove the
corresponding arguments at any call sites that simply specify "[]" or
"nil". Such arguments are basically noise, and tend to harm
readability when there are low-content argument labels like "with:" or
"for".
Some examples from Lister:
self.updateUserActivity(AppConfiguration.UserActivity.watch,
userInfo: userInfo, webpageURL: nil)
becomes
self.updateUserActivity(AppConfiguration.UserActivity.watch,
userInfo: userInfo)
and
contentView.hitTest(tapLocation, with: nil)
becomes
contentView.hitTest(tapLocation)
and
document.closeWithCompletionHandler(nil)
becomes simply
document.close()
and a whole pile of optional "completion handler" arguments go away.
Swift SVN r31978
The presence of a verb or preposition prior to the redundant part
provides a firm linguistic split that lets the actual argument fill in
for the reader. For other parts of speech (adjectives, especially)
it's awkward to transition from "reading part of the name" to "reading
the argument". This eliminates a significant number of bad omissions,
e.g., "setTextColor()" -> "setText()", and generally makes the
transformation more conservative.
Swift SVN r31656
Specifically, "Ref", "Ptr", and dimensionality suffixes (1D, 2D, 3D)
in the type name should not prevent us from finding redundancy in type
information.
Swift SVN r31428
Examples:
NSString's
@property (nonatomic, copy) NSString *uppercaseString;
becomes
var uppercase: String { get }
NSColor's
+(NSColor *)redColor;
becomes
class func red() -> NSColor
More heuristics for rdar://problem/22232287.
Swift SVN r31221
Update the importer and name lookup to prefer a factory initializer that is more available
over a convenience initializer that is less available even though we generally prefer
convenience initializers over convenience factory initializers. The motivation for this
change is CIColor, which has added a new convenience initializer:
- (instancetype)initWithRed:(CGFloat)r green:(CGFloat)g blue:(CGFloat)b NS_AVAILABLE(10_11, 9_0);
but already has existing convenience factory initializer:
+ (instancetype)colorWithRed:(CGFloat)r green:(CGFloat)g blue:(CGFloat)b;
Without this change we prefer -initWithRed:green:blue, so instantiating CIColor with:
let colorChannelValue: CGFloat = …
let ciColor = CIColor(red: colorChannelValue, green: colorChannelValue, blue: colorChannelValue)
results in an availability error even though there is a perfectly available convenience
factory initializer. With this change, we choose the convenience factory initializer
when importing, so there is no availability error.
rdar://problem/20617581
Swift SVN r30946
Otherwise, people subclassing NSView will accidentally call NSView.print
when they're trying to call Swift.print.
rdar://problem/18309853
Swift SVN r30334
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
...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
...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
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
This behaves like @UIApplicationMain, except for AppKit. Attach it to your NSApplicationDelegate, and an artificial "main" will be generated that invokes NSApplicationMain() for you. Implements rdar://problem/16904667.
Swift SVN r21697
...and 'assign' and 'unsafe_unretained' as 'unowned(unsafe)', if the
property is a class type.
This isn't important for the compiler, but it is documentation for users
when they look at the generated interface for an Objective-C module.
Note that this actually produces a decl users can't yet write:
unowned(unsafe) var foo: UIView!
That's <rdar://problem/17277899> unowned pointers can't be optional.
<rdar://problem/17245555>
Swift SVN r20433
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
This makes categories of NSString, NSArray, and NSDictionary available
on String, Array, and Dictionary. Note that we only consider
categories not present in the Objective-C Foundation module, because
we want to manually map those APIs ourselves. Hence, no changes to the
NSStringAPI. Implements <rdar://problem/13653329>.
Swift SVN r18920
We started tracking statistics for these in r16529, but because we've
"always" done this for initializers, it's trivial to just implement
the splitting. As with initializers, we synthesize a named argument of
type '()' to capture the part of the first selector piece that follows
the class name.
Swift SVN r16530
Factory initializers express an initializer that produces an object of
the given type, but is not inherited and not designated. Although they
have a syntactic form for presentation purposes (-> ClassName), there
is no way to specify or implement them within Swift. Rather, factory
initializers are created when importing an Objective-C factory method
that returns the class type rather than instancetype.
Swift SVN r16528
When an Objective-C class method follows the naming convention of a
factory method, i.e., its starting words match the ending words of the
class name, import it as a convenience initializer when it also:
- Returns instancetype (i.e., dynamic Self in Swift parlance)
- Has no NSError** parameters, which indicate the potential for failures
This is under a new flag (-enable-objc-factory-method-constructors)
because it is not generally functional. However, this is a step toward
<rdar://problem/16509024>.
Swift SVN r16479
methods with conflicting selectors.
We were doing this in a very ad hoc manner before; centralizing the
lookup table should make this significantly more robust. There's also
some scaffolding here to handle initializers better.
Fixes <rdar://problem/16516638>.
Swift SVN r16349
This makes a number of changes to the selector-splitting
heuristics. Specifically:
- Eliminate last-word splitting, and with it the notion of
multi-words. We only split at prepositions now.
- Introduce the notion of "linking verbs" such as "will" or
"should"; when these show up, we refuse to split a selector, which
helps with delegates.
- Eliminate the special case for "get" and "set". It wasn't
helping.
Swift SVN r16265
Seed the whitelist with the designated initializers for NSObject,
NSDocument, and UIDocument. We'll grow this list over time.
Fixes <rdar://problem/16521299>.
Swift SVN r16013
