Some foreign reference types such as IUnknown define retain/release operations as methods of the type.
Previously Swift only supported retain/release operations as standalone functions.
The syntax for member functions would be `SWIFT_SHARED_REFERENCE(.doRetain, .doRelease)`.
rdar://160696723
(cherry picked from commit e78ce6165f)
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
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: 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
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
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)
Explanation: When generating type names for template instantiations for
name mangling we did not generate correct names for reference types
resulting in collisions in the mangled names.
Issues: rdar://157237301
Original PRs: #83176
Risk: Low, the generated string is only used for name mangling.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Explanation: There were some scenarios where we could call an unsafe
function without marking the expression as unsafe. These affect mostly
cases where the function's result is passed to another function or
returned. This PR makes sure we always flag functions with unsafe return
types, even if their result is not stored anywhere for later use.
Issues: rdar://157237301
Original PRs: #83520
Risk: Low, worst case scenario the user has to add redundant unsafe
keywords in strict memory safe mode.
Testing: Added a compiler test.
Reviewers: @DougGregor
When we cannot respect the "destroy:" annotation, mark the type as
deprecated with a message thst says why there is a problem. There are
various potential problems:
* Multiple conflicting destroy functions
* Destroy functions that don't meet the pattern
* Type isn't imported as a move-only type
* Type has a non-trivial destructor (in C++)
(cherry picked from commit 63135e8929)
A C struct can be imported as noncopyable, but C doesn't have
destructors, so there is no way to provide user-defined logic to
perform the destruction. Introduce a new swift_attr that applies to
imported noncopyable types and which provides such a "destroy"
operation. It can be used like this:
typedef struct __attribute__((swift_attr("~Copyable")))
__attribute__((swift_attr("destroy:wgpuAdapterInfoFreeMembers")))
WGPUAdapterInfo { /*...*/ } WGPUAdapterInfo;
void wgpuAdapterInfoFreeMembers(WGPUAdapterInfo adapterInfo);
This will bring the WGPUAdapterInfo struct in as a noncopyable type
that will be cleaned up by calling wgpuAdapterInfoFreeMembers once it
is no longer in use.
Implements rdar://156889370.
(cherry picked from commit 6ba560fb4b)
In C interoperability mode, respect the ~Copyable annotation on C
structs to import them as ~Copyable types.
Fixes rdar://156877772.
(cherry picked from commit 21b9b9f713)
The code for handling Swift conforms_to attributes was specific to
C++ record types. Generalize it to work on typedefs imported as
nominal types, also in C.
Fixes rdar://156290361.
(cherry picked from commit c5db5cced5)
Most of the logic for C++ foreign reference types can be applied to C types as well. Swift had a compiler flag `-Xfrontend -experimental-c-foreign-reference-types` for awhile now which enables foreign reference types without having to enable C++ interop. This change makes it the default behavior.
Since we don't expect anyone to pass `experimental-c-foreign-reference-types` currently, this also removes the frontend flag.
rdar://150308819
(cherry picked from commit 9178af3ec7)
Especially in an explicit modules project, LLDB might not know all the
search paths needed to imported the on disk header.
rdar://157063577
(cherry picked from commit a6678476d8)
Previously this flag was only used to pass explicit dependencies to compilation tasks. This change adds support for the dependency scanner to also consider these inputs when resolving dependencies.
Resolves https://github.com/swiftlang/swift-driver/issues/1951
Explanation: C++ interop synthesizes certain forwarding functions in an
_ObjC module. This confuses MemberImportVisibility. This patch adds
logic to work this around by keeping a mapping between the synthesized
and the original function and looks up where the synthesized functions
belong to based on the original functions' parent module.
Scope: C++ forward interop when MemberImportVisibility is enabled.
Issues: rdar://154887575
Original PRs: #82840
Risk: Low, a narrow change makes getModuleContextForNameLookupForCxxDecl more
precise, and it is only used with MemberImportVisibility.
Testing: Added a compiler test.
Reviewers: @egorzhdan, @tshortli, @hnrklssn
Adds an access control field for each imported module identified. When multiple imports of the same module are found, this keeps track of the most "open" access specifier.
LookupOverloadedBinOp stores `Args` for later use, so store the
backing array on the stack instead of using a temporary.
This fixes a crash that appeared under some build configurations.
Related to rdar://154291418
(cherry picked from commit 75ac27dc3d)
This is a follow-up to https://github.com/swiftlang/swift/pull/82085
which made it so async variant doesn't get `@Sendable` inferred because
the proposal specified that inference should happen only on completion
handler parameter type of a synchronous variant of an imported API.
This runs into implementation issues related to thunking in some
cases were async convention expects the type of a completion handler
to match exactly for both variants of the imported API.
Resolves: rdar://154695053
(cherry picked from commit 30f0fa8d75)
Integer literal expressions with types that are not of type `int` are
printed with a suffix to indicate the type (e.g. `123U` or `456L` for
`unsigned` and `long`). This is not valid syntax for integer literals in
Swift, so until we fully translate the count expr syntax to Swift we
need to avoid importing these count expressions.
Also fixes some -Werror related stuff in test cases.
rdar://154141719
(cherry picked from commit 374658a)
When improving the speed of dependency scanning when the new clang API
to speed up bridging, some unintended change was introduced. This
restore the scanner to the behavior before #81454
rdar://153851818
(cherry picked from commit cebe173ada)
Functions that are isolated to a global actor don't have completion
handlers imported as `@Sendable`. Main actor isolated functions with
completion handlers that are always called on the main actor is a
very common Objective-C pattern, and this carve out will eliminate
false positive warnings in the cases where the main actor annotation
is missing on the completion handler parameter.
Resolves: rdar://149811049
(cherry picked from commit ab227b401d)
This lifts the check for the feature flag up into the `importParameterType`
from `importType` and means that completion handler type for `async` variant
is no longer gains `@Sendable` attribute.
(cherry picked from commit 74471e858b)
