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.
The current implementation of `-application-extension` has a problem that affects the generation of ObjC headers for regular Swift modules.
The primary purpose of `-application-extension` is to prevent the use of unavailable APIs in app extensions. However, it has an impact on the generation of -Swift.h headers and exposes Swift's internal declarations to ObjC. This behavior is appropriate for mixed modules that are not consumed externally, such as app extensions, but it fails to address the situation when a module is not an extension itself but is consumed by the extension (c90cd11).
To resolve this issue while maintaining the desired behavior, we can introduce a new flag for this particular use-case.
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
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
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
