When we parse a bridging header, start building a mapping from Swift
names (both base names and full names) to the Clang declarations that
have those names in particular Clang contexts. For now, just provide
the ability to build the table (barely) and dump it out; we'll grow
it's contents in time.
Before going and asking for the top level module, check for nullness.
In addition, only ask for the top level of the module that had a
redeclaration.
rdar://problem/23701588
When importing C declarations, one can come across a redeclaration due
to two different clang modules textually including the same header.
Previously, to decide visibility of a declaration from a particular
module, the module in which it is redeclarated had to exactly match the
one we saw before, so a struct defined in A.B.C might cause it to be
hidden in A.X.Y, because we were already popping off submodule names on
the "left hand side", so the module comparison was A != A.X.Y. If
someone imports A.X.Y and expects that struct, they won't see it.
Now, strip off submodules of the "right hand side", correctly comparing
if the top-level modules match (A == A).
This may have the effect of allowing more declarations to be visible
than before but it prevents weird situations where struct typedefs can
be hidden in overly complicated nested header includes normally found in
OS system headers.
rdar://problem/23588593
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.
Background: Clang has a set of base headers distributed with the compiler
that contain things like vector operations, stddef.h, and tgmath.h.
Swift also needs these headers in order to import C and Objective-C (not
really a surprise), so we symlink to them from lib/swift/clang/. When we
build installable packages, we actually copy them in.
Now the tricky part. Clang's headers are actually at a path like
"include/clang/3.6.0/include/tgmath.h". That "3.6.0" is the Clang version,
which allows multiple Clangs to be installed on a single system. Swift
currently links to the top-level directory, but of course it's only
guaranteed to work with a specific version of the Clang headers. So the
version number here is always the version of Clang we use to build Swift.
Rather than leave the (relatively meaningless) version number here, just
make the symlink point at the "3.6.0" directory rather than the "clang"
directory. This means Swift doesn't have to think about the version number
here at all.
rdar://problem/23223066
When auto-completing import decls, we should prioritize not-yet imported modules
over already-imported modules. To do so, we mark the latter with not-recommended tag.
This is a WIP to make CompilerVersion more general.
- Rename CompilerVersion to just "Version"
- Make version comparison general and put _compiler_version special logic
with its second version component in a specialized parsing function
- Add a generic version parsing function
Swift SVN r32726
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
