This patch re-enables diagnostics for unannotated C++ functions or
methods returning `SWIFT_SHARED_REFERENCE` types. These warnings now
fire only **once per source location**, even in the presence of multiple
template instantiations. This avoids diagnostic duplication that was a
key source of noise in the compilation of larger codebases.
These warnings were previously disabled starting in **Swift 6.2** via
[PR-#81411](https://github.com/swiftlang/swift/pull/81411) due to
concerns around false positives and excessive duplication in projects
adopting C++ interop. This patch addresses the duplication issue by
adding source-location-based caching, which ensures that a warning is
emitted only once per source location, even across template
instantiations with different types.
However, the false positive issue remains to be investigated and will be
addressed in a follow-up patch. Until that happens, the warnings are
gated behind a new experimental feature flag:
`WarnUnannotatedReturnOfCxxFrt`. This feature will be enabled by default
only after thorough qualification and testing on large C++ codebases.
rdar://154261051
I'm not able to reproduce the CI issue reported in rdar://143950805
locally. I don't have access to the logs from the failing bot link:
https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RD_test-simulator/5086.
So, I'm trying to re-enable this test and do some custom PR testing to
see if the bot is still failing.
rdar://143950805
When MemberImportVisibility is enabled we failed to find certain base
methods from the extensions when said base methods are imported from
C++.
rdar://154887575
This improves support for initializing instances of `std::optional` from Swift. Previously only a null optional could be initialized directly from Swift. Now instantiations of `std::optional` will get a Swift initializer that takes the wrapped value as a parameter.
rdar://118026392
This makes it possible to use trigger import-as-member for C++ functions declared within namespaces. Previously only functions declared at the file level were supported.
rdar://138930205
C code is highly likely to want to use pointers as references between dependent
structs, and we would like to be able to readily map these to lifetime-dependent
Swift values. Making C types addressable-for-dependencies ensures that any function
producing a dependency on such a value receives a stable in-memory address for that
value, allowing borrows and inout accesses to always be representable as pointers.
rdar://153648393
When importing C++ methods, Swift always assumes that methods named `begin()` and `end()` are unsafe, since these methods commonly return iterator types that are inherently unsafe in Swift.
Some additional logic in Sema tries to diagnose usages of `.begin()` and `.end()` from Swift and suggest safe alternatives. That logic had a null pointer dereference bug.
rdar://153814676 / resolves https://github.com/swiftlang/swift/issues/82361
We synthesize a Swift function that only calls a C++ funtion that
produces the default argument. We produce this function for each module
that imports the C++ function with the default argument. This symbol
needs to be public as it is created in the context of the Clang module
and used from the Swift module. To avoid the linker errors, we always
emit this function into the client which is also the right thing to do
as the whole body is a single function call.
rdar://138513915
Fix two IRGen tests that are failing on Android armv7 and disable eight ClangImporter, C++ Interop, and SILOptimizer tests, two of which that were already failing on other 32-bit platforms.
This adds support for `swift_name` attribute being used with C++ types that are declared within namespaces, e.g.
```
__attribute__((swift_name("MyNamespace.MyType.my_method()")))
```
Previously import-as-member would only accept a top-level unqualified type name.
rdar://138934888
Previously, we would get two copies, one accessing the pointee and one
when we pass the pointee as a method as the implicit self argument.
These copies are unsafe as they might introduce slicing. When
addressable paramaters features are enabled, we no longer make these
copies for the standard STL types. Custom smart pointers can replicate
this by making the lifetime dependency between the implicit object
parameter and the returned reference of operator* explicit via a
lifetime annotation.
rdar://154213694&128293252&112690482
The runtime logic for printing a foreign reference type is behind `if #available(SwiftStdlib 6.2, *)`, which means it won't run on older versions of macOS, even if you use a newer Swift runtime.
rdar://153735437
If a C++ namespace has redeclarations in a bridging header, printing AST for the namespace would crash the compiler. This is because such a redeclaration would not have an owning Clang module, and the AST printer did not account for that.
This change fixes the crash.
rdar://151715540
Some of these tests were marked as unsupported since they were only
checking for macOS and Linux. They seem to be passing on FreeBSD as
well, so enabling them here.
848fad00 introduced support for printing foreign reference types. It changes both the compiler and the runtime, and having the runtime change applied is required for the test to pass. Let's not try to run it with an old runtime.
This change also splits up a test for printing of value types from a test for printing of foreign reference types, since we don't have any runtime restrictions for value types.
rdar://153205860
This teaches ClangImporter to respect the `_Nonnull`/`_Nullable` arguments on templated function parameters.
Previously Swift would only import a non-annotated function overload. Using an overload that has either `_Nonnull` or `_Nullable` would result in a compiler error. The non-annotated overload would get imported with incorrect nullability: Swift would always assume non-null pointers, which was inconsistent with non-templated function parameters, which are mapped to implicitly unwrapped optionals.
With this change all three possible overloads are imported, and all of them get the correct nullability in Swift.
rdar://151939344
This patch makes sure we don't get warnings in strict memory safe mode
when using shared references. Those types are reference counted so we
are unlikely to run into lifetime errors.
rdar://151039766
