When importing C++ template classes like`Ref<T>` that have methods
returning `T*`, we face the following situation when `T` is a
`SWIFT_SHARED_REFERENCE` type:
1. Without `SWIFT_RETURNS_(UN)RETAINED` annotation: Swift compiler would
emit a warning (currently under experimental-feature flag
`WarnUnannotatedReturnOfCxxFrt`) _"cannot infer the ownership of the
returned value" when T is a SWIFT_SHARED_REFERENCE type_
2. With annotation: Compiler rejects it with this error: _"cannot be
annotated... not returning a SWIFT_SHARED_REFERENCE type"_
This affects WebGPU's smart pointer types (`WTF::Ref<T>,
WTF::RefPtr<T>`) and similar patterns in other C++ codebases.
In this patch I am fixing the logic for diagnostic
`returns_retained_or_returns_unretained_for_non_cxx_frt_values`. I'm
also making it a warning instead of an error to minimize the risk, as
this diagnostic has been a hindrance to the adoption of these
annotations in real codebases when templated functions and types are
involved. (Refer to
[PR-78968](https://github.com/swiftlang/swift/pull/78968))
rdar://160862498
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.
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 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
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
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
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
Afteri #83712 landed, let's make another try enabling addressable
parameters by default.
This reverts commit 61d60eb6ad, reversing
changes made to 670f69eadc.
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. Fixes#82183.
rdar://153081347
