In Swift 6.1, we introduced warnings for C++ APIs returning
SWIFT_SHARED_REFERENCE types that lack the SWIFT_RETURNS_(UN)RETAINED
annotations. These warnings serve as a reminder to annotate APIs, as the
absence of these annotations can lead to arbitrary assumptions about the
ownership of returned SWIFT_SHARED_REFERENCE values. This could result
in both use-after-free (memory safety) bugs and memory leaks.
We have received feedback from a few adopters indicating potential false
positive cases where these warnings are triggered. Consequently, we have
decided to disable these warnings in Swift 6.2 and re-qualify the
warnings on larger projects to ensure their effectiveness and eliminate
false positives. Our intention is to re-enable the warnings in later
beta releases of Swift 6.2 once we have stronger evidence of their
effectiveness on large codebases and proof that there are no false
positives.
rdar://150937617
rdar://150800115
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
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".
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.
