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
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
Split the base name at the last preposition, but *only* when the first
parameter is defaulted, because defaulted arguments might not show up
at the call site and the longer base name can feel odd in such
cases. With this, stop avoiding the argument label "with": it's fine
when we have actual context at the call site, and the "with: nil" case
no longer happens now that we're defaulting nil.
Swift SVN r32098
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
When omitting words from the end of the base name because it is
redundant with the type of the first parameter leaves a hanging "With"
in the base name, drop that "with" and instead use the tail of the
base name as the label for the first parameter. The poster child for
this is -copyWithZone, which now turns into "copy(zone:)":
- func copyWith(_: NSZone) -> AnyObject
+ func copy(zone: NSZone) -> AnyObject
The intuition behind this change is that the "With" is stating that
the method isn't directly acting on its argument; rather, the argument
is something additional, and argument labels are a fine way to model this.
Swift SVN r31836
When the prefix of a method/property name is restating the result
type, followed by "By" and then a gerund, drop everything up to the
gerund. For example:
func stringByAppendingString(string: String) -> String
becomes
func appending(string: String) -> String
Swift SVN r31683
When the type name we're looking at is a collection of some element
type, also try to match the plural form of the element type name. For
example:
- func deselectItemsAtIndexPaths(_: Set<NSIndexPath>)
+ func deselectItemsAt(_: Set<NSIndexPath>)
Swift SVN r31666
diagnostics around invalid references to unavailable declarations, resolving
<rdar://problem/22491394> References to unavailable decls sometimes diagnosed as ambiguous
and a complex case exposed working through rdar://21928143.
Swift SVN r31587
The new option -Womit-needless-words finds places where names are
redundant with type information, producing warnings and Fix-Its to
shorten the names. Part of rdar://problem/22232287, to help bring
the same heuristics we're applying in the Clang importer to the user's
Swift code.
Swift SVN r31234
And give a proper warning when you use 'try?' in a non-failable init.
And do the right thing when trying to SILGen 'try?' delegating to a
failable throwing init.
And make sure DI understands that this is, in fact, an initialization.
More rdar://problem/21692467
Swift SVN r31060
The defer body func is only ever fully applied, so SILGen can avoid allocating a closure for it if it's declared as a 'func', making it slightly more efficient at -Onone.
Swift SVN r30638
CSApply). The code is somewhat simpler there, more correct (fixing the FIXME in the
testcase) and doesn't run afoul of CSDiags trying to type check partial AST
subexpressions.
Swift SVN r30425
Otherwise, people subclassing NSView will accidentally call NSView.print
when they're trying to call Swift.print.
rdar://problem/18309853
Swift SVN r30334
avoid emitting this diagnostics. They are always irritating to it because they
are duplicative with whatever the actual type constraint problem is. It also
interferes with there recursive structure of the problem.
Disabling them also allows us to shorten the black list of expr nodes that cannot
be handled in typeCheckIndependentSubExpression.
Swift SVN r30122
... by reimplementing the DiscardAssignmentExpr checker in MiscDiagnostics
instead of being in CSApply (which gets run on partial expression ASTs).
Also, when type checking and salvaging an expression fails, do not generate
structural diagnostics in addition to the type checker diagnostics, they are
just noise.
Swift SVN r29937
Enhance fixItRemove() to be a bit more careful about what whitespace it leaves around: if the thing it is removing has leading and trailing whitespace already, this nukes an extra space to avoid leaving double spaces or incorrectly indented results.
This includes an extra fix for looking off the start of a buffer, which extractText doesn't and can't handle.
This fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29449
if the thing it is removing has leading and trailing whitespace already, this nukes
an extra space to avoid leaving double spaces or incorrectly indented results. This
fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29419
getTypeOfIndependentSubExpression() might replace some values in the
given expression with OpaqueValueExprs, but if the type checker
decided to insert the corresponding OpenExistentialExpr at the top
level, the AST would now be in an inconsistent state, since
getTypeOfIndependentSubExpression() does not return a new expression
to the caller.
Ideally we would separate out type checking from expression rewriting
so that the latter is only performed when we know the expression
type checks, but that is a bigger project. For now, erase open
existentials after re-typechecking a sub-expression.
Fixes <rdar://problem/20598568>.
Swift SVN r29400
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
