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
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.
rdar://154969620
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++)
Normally, Swift cannot import an incomplete type. However, when we are
importing a SWIFT_SHARED_REFERENCE type, we're always dealing with
pointers to the type, and there is no need for the underlying type to
be complete. This permits a common pattern in C libraries where the
actual underlying storage is opaque and all APIs traffic in the
pointer, e.g.,
typedef struct MyTypeImpl *MyType;
void MyTypeRetain(MyType ptr);
void MyTypeRelease(MyType ptr);
to use SWIFT_SHARED_REFERENCE to import such types as foreign
references, rather than as OpaquePointer.
Fixes rdar://155970441.
Not setting this correctly can lead to an assertion failure in the AST verifier:
AbstractStorageDecl's setter access is out of sync with the access actually on the setter
Fixes#82637
rdar://154685710
Unfortunately, addressable parameters are viral, the whole dependency
chain needs to be consistent otherwise we get deserialization errors
when loading a module. The solution is to universally enable addressable
parameters for C++ interop but there are some blockers at the moment
that need to be solved first. Temporarily revert these changes until
those blockers are resolved.
This reverts commit b00ff4568b, reversing
changes made to 396379ecbf.
We've started seeing build failures where the conformance of a `std::vector` instantiation to `CxxVector` is missing. This was because the LifetimeDependenceInfoRequest triggers the protocol conformance table for the instantiation to be built before the synthesized conformance gets added.
This works around the issue by preventing LifetimeDependenceInfoRequest from running for the synthesized default argument generator function, which was the culprit of this particular failure.
rdar://155977071
When importing custom availability domains with dynamic predicates from Clang
modules, synthesize predicate functions for `if #available` queries and call
them when generating SIL.
Resolves rdar://138441312.
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
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
Importing C++ class templates in symbolic mode has proven to be problematic in interaction with other compiler features, and it isn't used widely. This change removes the feature.
rdar://150528798
Extends PR #79986 by adding support for calling parameterized C++ initializers from Swift. This patch synthesizes static factory methods corresponding to C++ parameterized constructors, allowing Swift to call them as Swift initializers (e.g., init(_:), init(_:_:), etc.). This patch also aded tests and logic to make sure that we emit no additional diagnostics when a C++ foreign ref type is just referred from Swift and its initializer is not explicitly called.
rdar://148285251
Building on top of PR #79288, this update synthesizes a static factory method using the default new operator, with a call to the default constructor expression for C++ foreign reference types, and imports them as Swift initializers.
rdar://147529406
In Swift, only value types can have mutating instance member functions
or computed properties. The importer logic was violating this invariant
when generating setters for bit fields of shared references.
Fixes#80182
