...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
There's also a testing option, -serialize-debugging-options, to force this
extra info to be serialized even for library targets. In the long run we'll
probably write out this information for all targets, but strip it out of
the "public module" when a framework is built. (That way it ends up in the
debug info's copy of the module.)
Incidentally, this commit includes the ability to add search paths to the
Clang importer on the fly, which is most of rdar://problem/16347147.
Unfortunately there's no centralized way to add search paths to both Clang
/and/ Swift at the moment.
Part of rdar://problem/17670778
Swift SVN r24545
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
This affects the MacTypes.h header in the Darwin module as well as the
CarbonCore and OSServices sub-frameworks of the CoreServices framework.
API hidden in this way can still be accessed through qualified lookup
in case it's really needed, but will not appear in the module interface
or in code completion.
This is a hack, and it would be nice to remove it if/when all of this API
is officially marked as deprecated. I did check with Nick for MacTypes.h
and Chris Linn from CoreServices that this was a reasonable action to take.
rdar://problem/16806148
Swift SVN r24424
Use the CodeGenOptions the Clang frontend determined for the compiler instance instead of starting from scratch, so that we pick up important settings like '-mstackrealign'. Fixes the GLKit test on iOS. rdar://problem/19180367
Swift SVN r23792
