When compiling a Swift module in incremental mode, each Swift source file is compiled into an object file
and we use linker to link them together. Because the predicate function for checking dynamic feature
availability is eagerly synthesized per compilation unit, the linker will complain about duplicated
symbols for them. Setting their visibility as private ensures that linker doesn't see them, thus addressing
the linker errors.
One workaround for this problem is to enable WMO.
rdar://164971313
For dynamic features defined from a header, we synthesize a pure Clang function to check whether the feature should
be enabled at runtime. Swift modules don't have capability to deserialize this clang predicate function, leading to
crasher as a result. This change fixes the crasher by hiding the synthesized function to be a module internal one.
rdar://164410957
Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
When creating a C++ method that thunks from a particular C++ derived
class to call a method on one of its base classes, we do some manual
name mangling. This name mangling did not properly capture all of the
aspects of the thunk, so it was prone to collisions.
In moving to SIL asmname, we got a different set of collisions from
the ones that existed previously. Expanding the mangling to account
for small differences (const or not) as well as the base class type
eliminates these collisions. Most of the test changes account for the
new mangling, but the member-inheritance test indicates that this
change fixes an existing miscompile as well.
We stumbled upon an old workaround that disabled the synthesis of Swift default expressions for C++ function parameters that don't have a name.
This change removes the workaround.
rdar://162310543
`span` is not available in all versions of libstd++, so make it a
conditional header. Also adds other missing c++20 headers.
Fixing this triggered an assert when importing a constant initialized
`wchar_t` variable, so that is also fixed. The reason is that `wchar_t`
is mapped to `Unicode.Scalar`, which cannot be directly initialized by
integer literals in Swift, triggering an assert when looking up the
protocol conformance for `_ExpressibleByBuiltinIntegerLiteral`.
rdar://162074714
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
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.
