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
(cherry picked from commit 124055a51a)
Explanation: 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.
Issues: rdar://160182651
Original PRs: #82333
Risk: Low, this is merged to main in early July and no one complained
yet. And the change is straightforward.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Fixes a regression caused by the `self` declaration being given a `DynamicSelfType`
even though the formal type of the enclosing function sometimes still uses the
concrete base class type.
Fixes#83876 | rdar://158956768.
Explanation: 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. This fix is
required to unblock a high priority libc++ change that fixes an
unintended ABI break.
Issues: rdar://159928354
Original PRs: #84105
Risk: Medium. I believe this is the right change but hard to anticipate
if something depends on the presence of these operations (which is
likely to be a bug). But this is required to unblock an important libc++
fix.
Testing: Added a compiler test.
Reviewers: @rjmccall
When we tried to create a std::optional of a nonescapable type in Swift, the compiler would run into an assertion failure.
This is because std::optional has an anonymous union where one of its members would be of this nonescapable type.
Turns out that we were not handling anonymous unions with nonescapable members correctly.
Fields of anonymous unions are injected to the parent as IndirectFieldDecl, so we need to handle these indirect fields the same way we handle "normal" fields.
rdar://156704699
Explanation:These objects are behind typedefs and user code supposed to
use the typedef names. We already have some logic in place for Obj-C
interop. Reuse the same logic for C++ to use the correct names.
Issues: rdar://150453489
Original PRs: #83670
Risk: Low, only OS object types are affected and they were problemtic
before the change.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Otherwise, when multiple workers encounter a diagnostic simultaneously we can encounter races which lead to corrupted diagnostic data or crashes
Resolves rdar://159598539
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
(cherry picked from commit 0a766e59ce)
rdar://159143492
Previously all bits after the spare bits of the first element were marked as spare bits. This caused enum tags to be stored in bits used by the payload.
Explanation: We generate forwarding calls for virutal methods. These forwarding
calls had a type error when the original parameter had an rvalue reference type.
In those scenarios we need to insert a static cast to make the type checker happy.
Issues: rdar://154969620
Original PRs: #83453
Risk: Low, narrow fix.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Explanation: Whenever we have a vector type, the escpability depends on the
escapability of the element type. This will enable us to consider more type
like std::vector<simd::float3> as safe by default.
Issues: rdar://157141552
Original PRs: #83542
Risk: Low, narrow fix.
Testing: Added a compiler test.
Reviewers: @egorzhdan
ExplanationThese types are passed around as reference counted pointers,
so the optional representation of them are nullable pointers.
Previously, we tried to wrap them in swift::Optional.
Issues: rdar://157667946
Original PRs: #83609
Risk: Low, the fix is narrow.
Testing: Added a compiler test.
Reviewers: @hnrklssn
Explanationi: When inheriting constructors, we define the inherited ctors in the derived class. We should not do that for copy and move operations as these operations can never be invoked (the implicit/defined/deleted ctor in the derived class always takes precedence). This fixes an issue where the lifetime parameters are not getting inferred for these spurious constructor definitions. This should also save us from doing some redundant work in the importer.
Issues: rdar://153081347
Original PRs: #83694
Risk: Low, we do not import some ctors that can never be called.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Explanationion: Function pointer types wee always considered fragile in
C++ mode, this manifested as a regression when interfacing with glibc.
Issues: rdar://159184118
Original PRs: #84040
Risk: Low, this only removes a spurious error for library evolution.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Otherwise the "nonisolated nonsending by default" mode blows up as
distributed thunk signatures dont match expectations.
This undoes the fix from https://github.com/swiftlang/swift/pull/83940
and applies the fix on the synthesis side of the distributed thunks,
such that they are @concurrent always -- which keeps their old semantics
basically, regardless of what "default" mode we have.
Explanation: We generate declarations in the C++ interop header with
"unavailable" annotations when we cannot export something to C++. These
declarations can collide with existing names. Previously, there were no
ways to resolve these name collisions. This PR introduces a new
attribute to hide declarations from the interop header.
Issues: rdar://158843666
Original PRs: #82616
Risk: Low, this adds a new, straightforward code path.
Testing: Added a compiler test.
Reviewers: @egorzhdan
If a guaranteed value is used in a dead-end exit block and the enclosing value is _not_ destroyed in this block, we end up missing the enclosing value as phi-argument after duplicating the loop.
TODO: once we have complete lifetimes we can remove this check again.
rdar://159125605
the new NonisolatedNonsendingByDefault upcoming feature breaks remote
calls in distributed actors, because the expected isolation doesn't
match and the runtime swift_distributed_execute_target_resume will
crash.
This is a short term fix to unblock adopters, however preferably we
should mark the thunks as nonisolated(nonsending), though that seems to
be more involved.
resolves rdar://159247975
It is valid to leak a value on paths into dead-end regions.
Specifically, it is valid to leak an `alloc_box`. Thus, "final
releases" in dead-end regions may not destroy the box and consequently
may not release its contents. Therefore it's invalid to lower such final
releases to `dealloc_stack`s, let alone `destroy_addr`s. The in-general
invalidity of that transformation results in miscompiling whenever a box
is leaked and its projected address is used after such final releases.
Fix this by not treating final releases as boundary markers of the
`alloc_box` and not lowering them to `destroy_addr`s and
`dealloc_stack`s.
rdar://158149082
If the argument type is an array and it's passed to an imported declaration
that accepts a raw pointer, the solver should use an "array-to-c-pointer"
conversion instead of the one for pointers.
Resolves: rdar://158629300
(cherry picked from commit 29b04f4a63)
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
(cherry picked from commit b440c4ff70)
Release/retain functions for C++ foreign reference types might return a reference count as an integer value.
Swift previously emitted an error for such functions, saying that the retain/release functions need to return void or a reference to the value.
rdar://157853183
(cherry picked from commit 3887ed0637)
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
(cherry picked from commit c73f528b82)
