This is functional for arbitrary Objective-C properties and methods
(the subject of rdar://problem/22214302), as well as for changing the
argument labels of C functions. However, it does not work when the
name of a global is changed because name lookup initiated from
Swift goes through the Swift lookup table. Fixes
rdar://problem/22214302 but is only a step toward
rdar://problem/17184411.
Swift SVN r32670
Prepend "is" to Boolean property names (e.g., "empty" becomes
"isEmpty") unless the property name strongly indicates its Boolean
nature or we're likely to ruin the name. Therefore, the presence of
one of the following in the property name will suppress this
transformation:
* An auxiliary verb, such as "is", "has", "may", "should", or "will".
* A word ending in "s", indicating either a plural (for which
prepending "is" would be incorrect) or a verb in the continuous
tense (which indicates its Boolean nature, e.g., "translates" in
"translatesCoordinates").
Swift SVN r32458
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
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
This makes Swift (a) more likely to prefer frameworks over bare headers,
reducing potential issues with non-modular headers, and (b) more likely
to fail in the same way as LLDB if the -Xcc options also contain or affect
search paths.
rdar://problem/22413525
Swift SVN r31950
- We shouldn't add flags based on other flags.
- We shouldn't add frontend flags if we can help it, and need to use -Xclang
if we can't help it.
This is steps towards compiling; we can make the tests pass later.
Swift SVN r31805
(And unions, and enums. Now with a fix for forward declarations.)
This isn't common, but we shouldn't break when it happens.
rdar://problem/22570681
Swift SVN r31692
This reverts r31684. C only allows one definition of a tag decl, formally,
so we shouldn't expect definitions in multiple modules. We certainly don't
want every /declaration/ to count as making a struct part of a module's
interface.
Swift SVN r31686
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
Sink the actual logic for omitting needless words way down into
Basic, so we can re-use it elsewhere. Tie the Clang importer into that
logic, mapping Clang types down to strings appropriately. NFC
Swift SVN r31233
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
The -enable-omit-needless-words option attempts to omit needless words
from method names imported from Clang. Broadly speaking, a word is
needless if it merely restates the type of the corresponding parameter,
using reverse camel-case matching of the type name to the
function/parameter name. The word "With" is also considered needless
if whether follows it is needless, e.g.,
func copyWithZone(zone: NSZone)
gets reduced to
func copy(zone: NSZone)
because "Zone" merely restates type information and the remaining,
trailing "With" is also needless.
There are some special type naming rules for builtin Objective-C types,
e.g.,
id -> "Object"
SEL -> "Selector"
Block pointer types -> "Block"
as well as some very-Cocoa-specific matching rules, e.g., the type
"IndexSet" matches the name "Indexes" or "Indices".
Expect a lot of churn with these heuristics; this is part of
rdar://problem/22232287.
Swift SVN r31178
This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
We blacklist most of CarbonCore, but UnicodeUtilities still has some
APIs that don't yet have newer replacements.
rdar://problem/21686090
Swift SVN r31150
What does that mean? We'll indeed parse the provided prefix header.
If you aren't using a bridging header, that's all you get -- nothing
extra is made visible. If you /are/ using a bridging header, the prefix
header is prepended to it...but none of the modular content it imports
is made visible. I cloned rdar://problem/22083824 to fix that.
The important thing is that we /won't/ try to import overlays before
we've even finished setting up all the module loaders, and therefore
won't crash.
rdar://problem/20893290
Swift SVN r30831
This was supposed to prevent crashes, but it ended up /causing/ crashes
because we may hit a fatal Clang error /while/ importing Clang modules
and bridging headers.
I left the test on the logic that imports bridging headers because that
happens under more controlled circumstances. (Clang modules that have
Swift counterparts should never have bridging headers.)
rdar://problem/21689014
Swift SVN r30512
This should have no functionality change, but is supposed to keep us from
accidentally relying on the "full" Clang importer when in a backend job.
I tested it by archiving a little iOS app from a developer.
Unfortunately, part of the motivation here was that we'd get error messages when
we pass something Clang doesn't like, and that doesn't seem to be happening.
rdar://problem/21389553
Swift SVN r30407
Due to the fact that AnyClass is not Hashable, and that currently
NSKeyedArchiver/Unarchiver work with NSObject-derived, NSCoding
compliant classes, we are marking the decodeObjectOfClasses API refined
for Swift in our objc header and providing the desired overlay in our
overlay as shown below.
Arrays were also considered (for both API), but the underlying
implementation is entirely set-based, and using Arrays in Swift vs Sets
in objective C felt like too far a deviation.
Patch by Michael LeHew Jr.
Changes to the Dictionary test are caused by bumping the Fonudation API
epoch and taking in a fix in the types used in an NSDictionary
initializer.
rdar://21486551
Swift SVN r30297
- Macros that aren't visible won't have macro info.
- Making a module visible to Sema doesn't make it visible to the Preprocessor.
Part of rdar://problem/21480635
Patch by Jordan Rose.
Swift SVN r29703
A method has "__" prepended to its basename; an initializer has "__"
prepended to its first argument.
There are a few holes here involving no-argument initializers and factory
methods, but hopefully we won't need to remap those with swift_private anyway.
More of rdar://problem/20070465
Swift SVN r29429
...including structs and struct fields, enums and enum cases, typedefs,
protocols, classes, and properties.
The main problem is that this /doesn't/ handle top-level /lookup/, so you
can't actually find any of these renamed types. This is fixed in the next
commit.
This does not handle methods, subscripts, or initializers.
Part of rdar://problem/20070465
Swift SVN r29427
If Clang->Swift functions are named "import*" ("importDecl", "importName",
etc.), then clearly Swift->Clang functions should be called "export*".
(Originally we called both directions "import", but recent additions have
used "export" for Swift->Clang instead.)
No functionality change.
Swift SVN r29424
On a factory method, swift_name can have two effects:
- If the custom name has a base name of "init", import the method as an
initializer, even if it doesn't follow the usual naming conventions.
- Otherwise, import the method as a method, even if it /would have/ been
imported as an initializer.
There's a bit of trickiness around NSError**: currently you have to specify
the name of the error parameter on the Clang side even if it's going to be
deleted on the Swift side. We may want to change this later.
The test cases here exposed the issues in the previous two commits,
so this effectively depends on those for passing tests.
More of rdar://problem/19240897.
Swift SVN r28979
This is a hack.
We currently don't put anything in Clang submodules; they're just wrappers
to track what is and isn't visible. All lookups happen through the top-
level module.
This commit adds a new API getImportedModulesForLookup, which is ONLY used
by top-level name lookup and forAllVisibleModules. It is identical to
getImportedModules for everything but ClangModuleUnits, which instead
compute and cache a list of their transitively imported top-level modules.
This speeds up building Foundation.swiftmodule with a release compiler by
a bit more than 5%, and makes a previously lookup-bound test case compile
a third faster than before.
This is a hack.
rdar://problem/20813240
Swift SVN r28598
