When determining whether a C++ method is safe to be imported, we look at its return type to see if it stores any pointers in its fields.
If the type is templated, we might not have its definition available yet. Unfortunately we cannot instantiate it on the spot, since the Clang AST would be read and written at the same time.
Let's stay on the safe side and treat such methods as unsafe.
rdar://107609381
The macro name resolution in the source lookup cache was only looking at
macros in the current module, meaning that any names introduced by peer
or declaration macros declared in one module but used in another would
not be found by name lookup.
Switch the source lookup cache over to using the same
`forEachPotentialResolvedMacro` API that is used by lookup within
types, so we have consistent name-lookup-level macro resolution in both
places.
... except that would be horribly cyclic, of course, so introduce name
lookup flags to ignore top-level declarations introduced by macro
expansions. This is semantically correct because macro expansions are
not allowed to introduce new macros anyway, because that would have
been a terrible idea.
Fixes rdar://107321469. Peer and declaration macros at module scope
should work a whole lot better now.
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
