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
Instead of importing everything and filtering later (so all of clang modules get deserialized and associated Swift decls get created),
lazily import as Swift decls only the Clang decls that we need from a particular header.
This also fixes printing ObjC categories in the header as Swift extensions.
Swift SVN r28358
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Change the active-platform availability logic to not consider iOS as active on
tvOS. We want all of the messiness of the fact that tvOS was branched
from iOS to be handled in clang, which "transcribes" iOS availability attributes
to their corresponding tvOS counterparts as long as there is not an
existing explicit tvOS availability attribute on the declaration.
This change exposed several places where I needed to add explicit handling of
of tvOS and where we will need to handle watchOS as well.
rdar://problem/20774229 tracks adding logic and tests to handle watchOS in these
places.
It is also unfortunately the case that llvm::triple returns true when isiOS()
is called on tvOS. This means that to test whether an llvm:triple target is
really iOS, we need to check for iOS then check explicitly that it is not
tvOS. We will eventually change llvm's behavior here so that the double
check is not needed.
Swift SVN r28013
I haven't been able to come up with a small reduced test case, and I don't
think I'm likely to in the near future, so I'd like to commit this for now.
This fixes the particular crash reported in rdar://problem/19975256, but
not the general problem. I have a heavier solution for that too, but don't
want to commit it just yet when I don't even have a test for this commit.
rdar://problem/19975256
Swift SVN r27196
...and bump our "Foundation epoch" guard to 3 to match.
Long-term we should switch to an attribute for "yes, this is really a set
of enumerated constants" (and "this is a set of related bitmask options"),
but this unblocks things for now, and doesn't cause any issue if we end
up doing something else.
rdar://problem/20418505
Swift SVN r26944
We have an SPI between the Swift compiler and Foundation based on the
SWIFT_SDK_OVERLAY_FOUNDATION_EPOCH preprocessor macro that allows us to
request the new API. rdar://20270080 tracks removing it.
Swift SVN r26475
This reverts commits r26369 & r26381.
After upstream clang changes, reverted r25843 which was compensating for a previous upstream clang change.
But keep test/IDE/complete_from_clang_framework.swift disabled for further investigation, because it
seems to have some duplications in a code-completion test.
rdar://20245658&20247922
Swift SVN r26430
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
This fixes the import of enums like NSCalendarUnit, which changed from
NSXXXCalendarUnit to NSCalendarUnitXXX, as has been the guideline in
recent years. Now even when the old names are present, we can still
prefix-strip based on the new names. If /all/ options are deprecated,
though, we'll prefix-strip as we did before.
Note that we /don't/ check the current deployment target for this,
because we want to use the "nice" names as soon as we have an SDK where
they're available, not when the deployment target matches such an SDK.
rdar://problem/17686122
Swift SVN r26184
...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 should help us avoid crashes like rdar://problem/19798049 in the future.
Of course, since fatal errors are so rare, I don't have a way to test this,
but it isn't breaking any of the paths we currently use.
rdar://problem/19827938
Swift SVN r25285
