This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
Fix a bug in expandExternalSignatureTypes where it wasn't annotating a function call parameter type with sret when the result was being returned indirectly.
The bug was causing calls to ObjC methods that return their results indirectly to crash.
Additionally, fix the return type for C++ constructors computed in expandExternalSignatureTypes. Previously, the return type was always void even on targets that require constructors to return this (e.g., Apple arm64), which was causing C++ constructor thunks to be emitted needlessly.
Resolves rdar://121618707
When importing a C++ class template instantiation, Swift translates the template parameter type names from C++ into their Swift equivalent.
For instance, `basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t>>` gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `wchar_t` is imported as `CWideChar`, which is a typealias for `Scalar` on most platforms including Darwin. Notice that Swift goes through the `CWideChar` typealias on the specific platform. Another instantiation `basic_string<uint32_t, char_traits<uint32_t>, allocator<uint32_t>>` also gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `uint32_t` is also imported as `Scalar`. This is problematic because we have two distinct C++ types that have the same name in Swift.
This change makes sure Swift doesn't go through typealiases when emitting names of template parameters, so `wchar_t` would now get printed as `CWideChar`, `int` would get printed as `CInt`, etc.
This also encourages clients to use the correct type (`CInt`, `CWideChar`, etc) instead of relying on platform-specific typealiases.
rdar://115673622
This change makes sure that `NSNotification.Name.NEVPNStatusDidChange` is imported correctly when C++ interop is enabled.
`importer::findSwiftNewtype` is called while writing Clang modules, at a point when the translation-unit scope does not exist (`clangSema.TUScope` is `nullptr`).
That prevents the Clang lookup from discovering `NSNotificationName` declaration.
Instead of trying to pass a translation-unit scope to Clang, let's use qualified name lookup which does not require a scope.
rdar://112199372
At some point several months ago the `INADDR_ANY` macro from `Darwin.POSIX` module was not imported into Swift correctly. The issue seems to be resolved now. This change adds a test to make sure we don't regress again.
rdar://107429566
This changes the heuristic that we use to detect `CF_OPTIONS`/`NS_OPTIONS` instantiations in C++ language mode.
Since libraries sometimes declare custom option types that break the assumptions about the names of such types, this lifts the requirements on the type name.
rdar://113524090
rdar://113279214
The existing synthesis mechanism had a bug: `cxxRecordDecl->hasDefaultConstructor()` returns true for C++ types with an implicit default constructor, for instance, `pthread_mutexattr_t`.
rdar://113708880
This Objective-C method
```
- (void)stream:(NSStream *)aStream
handleEvent:(NSStreamEvent)eventCode;
```
should be imported as
```
optional func stream(
_ aStream: Stream,
handle eventCode: Stream.Event)
```
and not
```
optional func stream(
_ aStream: Stream,
handleEvent eventCode: Stream.Event)
```
in order to stay compatible with Objective-C interop mode.
rdar://113208675
This fixes linker errors which occurred when using Foundation extensions to `Swift.String`, such as `func replacingOccurrences`.
After the last rebranch, Clang started wrapping certain types in `clang::ElaboratedType`. This caused CF_OPTIONS types such as `Foundation.NSTextCheckingType` to be imported incorrectly in C++ language mode (`NSTextCheckingType` was imported as `uint64_t` without getting the special treatment of a CF type), which was causing deserialization errors when Swift tried reading `Foundation.swiftmodule`. Those deserialization errors were silenced by default. The IR for those functions was not emitted, which caused linker errors later.
rdar://109830032
Previously ClangImporter was not able to lookup `NSObject` when C++ interop is enabled, which caused types such as `xpc_object_t` from system module XPC to be imported differently: `any OS_xpc_object` without C++ interop vs `any NSObject & OS_xpc_object` with C++ interop enabled.
rdar://110000787
This patch is an add-on to https://github.com/apple/swift/pull/64043.
Essentially when encountering NS_OPTIONS enums, in C++-Interop mode
if they are not specially handled then they can mangle differently than
they do without C++-Interop. This patch adds logic to handle when a
typedef and enum have additional clang::ElaboratedType sugar, but
otherwise it does the same as the existing 64043 patch.
The test case provided was encountered in a real app build. The problem
came from when two modules are each compiled one with and one without
C++-Interop. For the test case code provided the mangling of the
protocol conformance is not consistent and the code in
SILGenLazyConformance.cpp crashes on an invalid conformance with reason
"Invalid conformance in type-checked AST".
Currently without an initializer for the unsafe char pointer type swiftc
hits an assert around not being able to handle conversions of unsafe
pointers with Any type. This patch adds the ability to convert to a
std::string.
This is to address issue https://github.com/apple/swift/issues/61218
When instantiating C++ types who contain ARC types in the past either
their default constructors are skipped or they are synthesized with
Unmanged<> wrappers. This has made it more cumbersome to instantiate
these from Swift and often requires a static C++ build method to
manually shim the synthesized constructor. The following change drops
the Unmanaged<> so that for the time being these types can be
instantiated directly even if types like Swift -> NSString are not
bridged completely.
(cherry picked from commit accdace5f0438860a0d6760d9598402a9998a324)
(cherry picked from commit 567763c9ec76e14b0d6af5707e50b1674b2c2cbf)
Add a test case that checks the behaviour introduced during the refactor
of `importFunctionParameterList` and `importMethodParamsAndReturnType`.
The test checks that both Obj-C++ methods and C++ functions treat `const
T&` parameters in the same way.
When constructing SwiftLookupTable at clang module creation time, calls
to `clang::Sema::LookupName` will fail in C++ mode (including ObjC++).
The specific reason is that `clangSema.TUScope` (which we are passing in
as a Scope) is `nullptr` as we have no active Parser. The C++ path in
`clang::Sema::LookupName` is set to fail early and hard when the Scope
passed in is nullptr. In most, if not all, calls to `LookupName`, we
care about ObjC symbols and not C++ names. For example, the motivation
behind this issue is that ObjC protocols are not being renamed when
there is an ObjC class with the same name, leading to compilation
failures.
