PrintAsClang is supposed to emit declarations in the same order regardless of the compiler’s internal state, but we have repeatedly found that our current criteria are inadequate, resulting in non-functionality-affecting changes to generated header content. Add a diagnostic that’s emitted when this happens soliciting a bug report.
Since there *should* be no cases where the compiler fails to order declarations, this diagnostic is never actually emitted. Instead, we test this change by enabling `-verify` on nearly all PrintAsClang tests to make sure they are unaffected.
This did demonstrate a missing criterion that only mattered in C++ mode: extensions that varied only in their generic signature were not sorted stably. Add a sort criterion for this.
This is a new warning in clang when you use @import in a framework header. That’s often a mistake, but it isn’t in our generated -Swift.h headers. If we’re building with a clang that supports this warning, we’ll now emit a pragma to disable it.
The C preprocessor rules don't short-circuit so "#if defined(__has_feature) && __has_feature(modules)" will always fail if '__has_feature' is not defined.
This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
PrintAsObjC behaves slightly differently in apps vs. frameworks: for apps,
you get internal decls exposed in the header as well as public ones. This
is because the generated header is not being shipped anywhere and thus we
don't have a secrecy leak.
However, we were detecting whether we were in an app based on whether or
not we had a bridging header. That's no good for mixed-source apps where
there's no bridging header, so now we also check for a main entry point,
whether generated from @UIApplicationMain or @NSApplicationMain, or from
a script source file (main.swift).
rdar://problem/17877235
Swift SVN r24532
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
"...because the generated header for a framework is part of the framework's
public Objective-C interface, only declarations marked public appear in the
generated header for a Swift framework."
Just missed a case here when we decided to do things this way.
<rdar://problem/17796727>
Swift SVN r20653
The upshot of this is that internal decls in an app target will be in the
generated header but internal decls in a framework target will not. This
is important since the generated header is part of a framework's public
interface. Users always have the option to add members via category to an
internal framework type they need to use from Objective-C, or to write the
@interface themselves if the entire type is missing. Only internal protocols
are left out by this.
The presence of the bridging header isn't a /perfect/ way to decide this,
but it's close enough. In an app target without a bridging header, it's
unlikely that there will be ObjC sources depending on the generated header.
Swift SVN r19763
...and just outright import the bridging header if that's what's needed.
This means we'll use @class and @protocol whenever we're just using a class
or protocol in a type, but still import the enclosing module when we need
the definition. We'll also fall back to the module (or bridging header) if
we need something /else/ from C: a struct, a typedef, whatever.
<rdar://problem/17183425>
Swift SVN r18795
Importing a header with -import-objc-header causes the Clang importer to
provide an extra module to represent the header's content, and this was
showing up as "@import __ObjC;" in the /generated/ header for the target.
We should just not print anything there and let users import what's
necessary.
<rdar://problem/16917113>
Swift SVN r18081
When generating a header for the Swift half of a mixed-source framework,
we can't import the framework using @import, because that means a submodule
is trying to import a parent module before the module is done being built.
This currently isn't supported in Clang, though it only recently became an
error instead of being ignored.
Instead, we now assume that the framework will have an umbrella header with
the same name as the framework module, which is the same assumption Xcode
makes when you don't provide your own module map. I'm not too concerned about
people trying to build mixed-source frameworks who /don't/ have umbrella
headers.
This doesn't affect app targets at all, which use -import-objc-header instead
of a standalone underlying module.
<rdar://problem/16879704>
Swift SVN r17984
