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.
