CF_OPTIONS is defined differently in the SDK based on
a __cplusplus preprocessor branch. As a result, declarations
referencing CF_OPTIONS are mangled differently depending
on if C++ interop is enabled.
This meant a module compiled with cxx interop on could
not be linked with a module compiled without and vice versa.
This patch modifies the mangler such that the mangled names
are consistent. This is achieved by feeding the mangler a modified
AST node that looks like the Objective-C definition of CF_OPTIONS,
even when we have cxx interop enabled.
This modifies the ClangImporter to introduce an opaque placeholder
representation for forward declared Objective-C interfaces and
protocols when imported into Swift.
In the compiler, the new functionality is hidden behind a frontend
flag -enable-import-objc-forward-declarations, and is on by default
for language mode >6.
The feature is disabled entirely in LLDB expression evaluation / Swift
REPL, regardless of language version.
This adds the following four new options:
- `-windows-sdk-root`
- `-windows-sdk-version`
- `-visualc-tools-root`
- `-visualc-tools-version`
Together these options make one the master of Windows SDK selection for
the Swift compilation. This is important as now that the injection is
no longer done by the user, we need to ensure that we have enough
control over the paths so that the synthesized overlay is going to map
the files to the proper location.
Add '-validate-clang-modules-once' and '-clang-build-session-file' corresponding to Clang's '-fmodules-validate-once-per-build-session' and '-fbuild-session-file='. Ensure they are propagated to module interface build sub-invocations.
We require these to be first-class Swift options in order to ensure they are propagated to both: ClangImporter and implicit interface build compiler sub-invocations.
Compiler portion of rdar://105982120
ClangDiagnosticConsumer was initialized on the stack in a scope of 'if'
branch, and was passed to the DiagnosticEngine as a pointer. Then the
diagnostic engine was used outside the scope.
Instead, allocate the consumer in the heap, and pass to the engine with
`ShouldOwnClient` true. So the engine takes the ownership.
Speculative fix for rdar://105801504
C++ types that store pointers as fields are treated as unsafe in Swift. Types that store other types that in turn store pointers are also treated as unsafe.
Types that store raw C++ iterators are also treated as unsafe in Swift. However, a type that stores another type that stores a raw iterator was previously imported as safe. This change fixes that.
rdar://105493479
