This introduces support for converting a Swift closure that captures variables from its surrounding context into an instance of `std::function`, which is useful for working with C++ APIs that use callbacks.
Each instantiation of `std::function` gets a synthesized Swift constructor that takes a Swift closure. Unlike the previous implementation, the closure is _not_ marked as `@convention(c)`. The body of the constructor is created lazily.
Under the hood, the closure is bitcast to a pair of a function pointer and a context pointer, which are then wrapped in a C++ object, `__SwiftFunctionWrapper`, that manages the lifetime of the context object via calls to `swift_retain`/`swift_release` from the copy constructor and the destructor. The `__SwiftFunctionWrapper` class is templated, and is instantiated by ClangImporter.
rdar://133777029
This reverts commit 4f059033bb. The change
is actually not NFC since previously, there is a cache in the
CompilerInvocation that prevents the same CAS from the same CASOptions
from being initialized multiple times, which was relied upon when
running inside sub invocation. When switching to a non-caching simple
CASOption types, it causes every single sub instance will create its own
CAS, and it can consume too many file descriptors and causing errors
during dependency scanning.
rdar://164903080
Feedback in #85445 after it merged pointed out that the changes around
`createClangInvocation` are not necessary because `CompilerInvocation`
do not hold a reference to `clang::DiagnosticOptions`, only the
`clang::driver::Driver` does.
These changes undo the modifications done there and return the code to
the previous state (but keeps the changes around `createClangDriver`
which was causing the use-after-free).
We have been mangling extern "C" symbols when building with C++
interoperability, leading to incorrectly-mangled names such as
_Z6memset that should have been unmangled "memset". Fix this so we get
consistent mangling between C and C++ interoperability modes.
Fixes rdar://164495210.
Upstream LLVM in llvm/llvm-project#139584 changed `DiagnosticOptions`
from being a referenced counted object to just be a reference, not owned
by the `clang::DiagnosticEngine`.
In 0981b71090 (part of #82243), the usages
of the Swift repository were adapted to the new memory model, but it
introduced at least one use-after-free and a potential one around the
usage of Clang in the Clang Importer.
This commit tries to fix the use-after-free in both cases, by returning
a `unique_ptr` to the `clang::DiagnosticOptions`, which makes the
lifetime of the `DiagnosticOptions` match the lifetime of the variable
that uses it (normally a `CompilerInvocation`).
Other cases in 0981b71090 should be safe
because the lifetime of the `DiagnosticOptions` do not seem to propagate
beyond the scope of the functions where they live (but I am not fully
sure about the one in `IDETool/CompilerInvocation.cpp` completely).
This was causing compiler crashes during the test
`Interop/Cxx/stdlib/unsupported-stdlib.swift` which eventually uses
`createClangDriver` and tries to emit a diagnostic, which in some cases
was reading the memory from `DiagnosticOptions` when it was already out
of scope.
[cxx-interop] Make ClangDeclExplicitSafety request non-recursive
[cxx-interop] Do not import template type arguments
[cxx-interop] Check template argument safety in ClangDeclExplicitSafety
Doing so reduces opportunities for caching, but it's not obvious to me
that we benefit from such fine-grained caching. The benefit here is that
we also avoid the pitfalls of incremental caching, as illustrated by the
added test case. Finally, we eliminate the use of hasActiveRequest(),
which is an anti-pattern.
The search paths for apinotes are leaked when using compilation caching
but they are not needed like other search path because the apinotes are
found and stored inside include-tree.
rdar://164205657
Checking this upon import may overlook annotations that explicitly
mark a type as safe (or unsafe). Instead, we consolidate this logic in
the ClangDeclExplicitSafety request.
rdar://163196609
This change just stages in a few new platform kinds, without fully adding
support for them yet.
- The `Swift` platform represents availability of the Swift runtime across all
platforms that support an ABI stable Swift runtime (see the pitch at
https://forums.swift.org/t/pitch-swift-runtime-availability/82742).
- The `anyAppleOS` platform is an experimental platform that represents all of
Apple's operating systems. This is intended to simplify writing availability
for Apple's platforms by taking advantage of the new unified OS versioning
system announced at WWDC 2025.
- The `DriverKit` platform corresponds to Apple DriverKit which is already
supported by LLVM.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
Checking this upon import was overlooking annotations that explicitly
mark a type as safe (or unsafe). Instead, we consolidate this logic in
the ClangDeclExplicitSafety request.
rdar://163196609
Any safe wrapper expansion originating in a bridging header would fail
typechecking because the `__ObjC` module doesn't import the standard
implicit imports. This is because the main module is not available to
inherit implicit imports from when the `__ObjC` module is created. We
don't need all of the implicit modules for safe wrappers, so import
`Swift` specifically.
rdar://163078116
