In libc++, `std::optional` inherits from several mixin base types. Some of those base types do not declare a deleted copy constructor for non-copyable value types, which works fine because clients are not supposed to use those base types directly from C++.
Swift, however, imports all of the transitive base types when importing a C++ type. As part of this, ClangImporter will attempt to instantiate e.g. `std::__optional_copy_assign_base<NonCopyable>`, and will fail with a hard error while doing so.
rdar://152718041
Make sure they are excluded from the reflection metadata (although in
the future we want to make sure indirect fields are included). Make sure
the users cannot refer to the anonymous field, only its members.
[ASTPrinter] Escape @_lifetime arguments when needed
Printing a LifetimeDescriptor would never wrap it in backticks (even if originally wrapped in backticks). This would result in the output not being able to be parsed
rdar://159992995
Anonymous structs cannot be copied or moved, these operations only can
happen to their enclosing non-anonymous types. Stop trying to emit
special member functions and value witness tables for these structs.
On rebranch the `captures(none)` attribute comes after `sret`.
Both the syntax and relative order of the LLVM `nocapture` parameter
attribute changed in llvm/llvm-project#123181.
This can help work around problems when the names of a C++ declaration
and a Swift declaration would collide, or to temporarily work around
compiler bugs.
rdar://152838988&140802127&158843666
This adds CxxStdlib overlay features to `std::wstring` similarly to `std::string`, `std::u16string`, etc.
This lets clients e.g. convert between Swift String and C++ wide string simply by calling an initializer.
rdar://159272493
This patch improves the warning for C++ APIs returning
`SWIFT_SHARED_REFERENCE` types but not annotated with either
`SWIFT_RETURNS_RETAINED` or `SWIFT_RETURNS_UNRETAINED` in the following
ways:
1. The warning for missing `SWIFT_RETURNS_(UN)RETAINED` annotations is
now emitted on Swift use sites, rather than while importing the API
(func/method decls).
- This logic is now implemented as a Misl Diagnostic in function
`diagnoseCxxFunctionCalls` in file lib/Sema/MiscDiagnostics.cpp.
- The warning is now triggered only when the API is actually used, which
reduces noise in large C++ headers.
- These warnings are still gated behind experimental-feature-flag `WarnUnannotatedReturnOfCxxFrt`
rdar://150800115
Disable Cxx tests failing on failed import of incorrectly imported
voidify symbol. This isn't just a FreeBSD issue, it's related to how we
import libcxx. Apple has a modified libcxx module to work around the
issue, but is not implemented in the copy on FreeBSD.
rdar://121551667
```
[2025-08-25T14:24:03.682Z] ld.lld: error: undefined hidden symbol: void* std::__1::__voidify[abi:se190107]<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&)
[2025-08-25T14:24:03.682Z] >>> referenced by use-std-optional-a50ecf.o
[2025-08-25T14:24:03.682Z] >>> /tmp/lit-tmp-_7a7wdmg/use-std-optional-a50ecf.o:(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>* std::__1::__construct_at[abi:se190107]<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&))
[2025-08-25T14:24:03.682Z] >>> referenced by use-std-optional-a50ecf.o
[2025-08-25T14:24:03.682Z] >>> /tmp/lit-tmp-_7a7wdmg/use-std-optional-a50ecf.o:(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>* std::__1::__construct_at[abi:se190107]<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&&))
[2025-08-25T14:24:03.682Z] clang: error: linker command failed with exit code 1 (use -v to see invocation)
[2025-08-25T14:24:03.682Z] <unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
```
When calling a C++ function that takes a reference to a pointer to a foreign reference type, Swift would previously pass a pointer to the foreign reference type as an argument (instead of a reference to a pointer), which resulted in invalid memory accesses.
This was observed when using `std::vector<ImmortalRef*>::push_back`.
rdar://150791778
This enables the use of reference-counted foreign reference types on Windows. As it turns out, the assertion that was failing on Windows previously was unnecessary. This also enabled many of the tests on Windows.
rdar://154694125 / resolves https://github.com/swiftlang/swift/issues/82643
This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
Reverse interop has logic that avoids emitting ambiguous overloads into the generated header. That logic did not apply for functions declared within Swift extensions. This meant that the generated C++ header would sometimes not compile.
rdar://158252800
Swift validates the retain/release operations for foreign reference types to check for obvious errors, e.g. a wrong parameter type or return type.
That logic was only running for C++ foreign reference types. This patch enables it for C foreign reference types as well.
rdar://158609723
This fixes a runtime crash when a `weak` reference to a C++ foreign reference type is used.
Instead of a runtime crash, Swift would now emit a compiler error saying that `weak` keyword is incompatible with foreign reference types.
rdar://124040825 / resolves https://github.com/swiftlang/swift/issues/83080
These are the minimal changes to make the reverse interop header compile
when embedded Swift is used. Previously, the _SwiftStdlibCxxOverlay.h
and the generated interop header disagreed on the mangling of a symbol.
This is not sufficient yet to use the embedded Swift standard library from
reverse interop, there are some missing symbols while linking. But this
PR enables doing reverse interop without using the stdlib types like
swift::String in C++. Follow-up PRs will fix the rest of the issues.
rdar://154740225
After #83289 and #82879 landed we should no longer get deserialization
failures and this feature is no longer behind a flag. This patch also
changes how we query if a function's return value depends on self.
Previously, we queried the lifetime dependencies from the Swift
declaration. Unfortunately, this is problematic as we might have not
finished fully importing the types in the function signature just yet
and the compiler might end up populating the conformance tables
prematurely. To work this around, I store functions with self-dependent
return values where lifetimes are computed in the importer for later
use.
The PR also adds a test to make sure the addressable dependency feature
will not result in deserialization errors.
rdar://155319311&154213694&112690482&128293252
