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
The order of lookups affects the order of imports, which can sadly end up
causing different behavior down the line.
The sort is by Clang TU source order, which isn't wonderful but should be
consistent. There are generally fewer decls without source locations that
come from Clang.
Swift SVN r28578
For the moment, we do not consider APIs deprecated earlier than watchOS 2.0 as
unavailable. rdar://problem/20948019 track changing this once the ultimate
decision on this policy has been made.
This addresses the compile-time components of rdar://problem/20774229
Swift SVN r28559
