**Explanation**:
In Swift 6.1, we introduced warnings for C++ APIs returning
`SWIFT_SHARED_REFERENCE` types that lack the
`SWIFT_RETURNS_(UN)RETAINED` annotations. These warnings serve as a
reminder to annotate APIs, as the absence of these annotations can lead
to arbitrary assumptions about the ownership of returned
`SWIFT_SHARED_REFERENCE` values. This could result in both
use-after-free (memory safety) bugs and memory leaks.
We have received feedback from a few adopters indicating potential false
positive cases where these warnings are triggered. Consequently, we have
decided to disable these warnings in Swift 6.2 and re-qualify the
warnings on larger projects to ensure their effectiveness and eliminate
false positives.
- **Scope**: Disabling a previously shipped warning. There is no
likelihood of any source breakage or semantic alterations.
- **Issues**: rdar://150937617 , rdar://150800115
- **Original PRs**: N/A
- **Risk**: Low
- **Testing**: Lit test and adopted manually on a demo Xcode project
- **Reviewers**: N/A Our intention is to re-enable the warnings in later
beta releases of Swift 6.2 once we have stronger evidence of their
effectiveness on large codebases and proof that there are no false
positives.
The warnings that ClangImporter emits about issues it encounters while
importing declarations from Clang modules should all belong to a diagnostic
group so that users of `-warnings-as-errors` can control their behavior using
the compiler flags introduce with SE-0443. It's especially important that these
diagnostics be controllable since they are often caused by external
dependencies and therefore the developer may not have any control over whether
they are emitted.
The `#ClangDeclarationImport` diagnostic group is intentionally broad so that
developers have a way to control all of these diagnostics with a single
`-Wwarning` flag. I fully expect that we'll introduce finer-grained diagnostic
groups for some of these diagnostics in the future, but those groups should be
hierarchically nested under `#ClangDeclarationImport`, which is supported by
SE-0443.
Resolves rdar://150524204.
In #80786, we started importing certain padded fields as opaque blobs.
Part of this logic involved querying those fields' ASTRecordLayout.
However, dependent types (which are imported symbolically) do not have
an ASTRecordLayout, so calling Clang's getASTRecordLayout() would lead
to an assertion error for class templates where a no_unique_address
field is some kind of dependent C++ record type.
This patch avoids the field padding check during symbolic import mode
because that check is only relevant for codegen anyway.
rdar://150067288
(cherry picked from commit 1fdb239cea)
Swift started to explicitly forbid the instantiation of C++ function
templates with arbitrary types in #77430, because many types cause the
Swift compiler to crash. However, those checks prevented them from being
instantiated with Swift closures (which were previously fine), causing
a regression.
This patch relaxes the convertTemplateArgument() function to also allow
converting Swift function types, and adds some tests to make sure doing
so is fine.
This patch also does some cleanup of existing tests checking the
instantiation of various types, and adds testing for C function pointers
and Obj-C blocks.
rdar://148124104
(cherry picked from commit 284de98744)
It is possible for a C++ class template to inherit from a specialization
of itself. Normally, these are imported to Swift as separate (unrelated)
types, but when symbolic import is enabled, unspecialized templates are
imported in place of their specializations, leading to circularly
inheriting classes to seemingly inherit from themselves.
This patch adds a check to guard against the most common case of
circular inheritance, when a class template directly inherits from
itself. This pattern appears in a recent version of libc++,
necessitating this patch. However, the solution here is imperfect as it
does not handle more complex/contrived circular inheritance patterns.
This patch also adds a test case exercising this pattern. The
-index-store-path flag causes swift-frontend to index the C++ module
with symbolic import enabled, without the fix in this patch, that test
triggers an assertion failure due to the circular reference (and can
infinitely recurse in the StorageVisitor when assertions are disabled).
rdar://148026461
(cherry picked from commit 1f2107f357)
Explanation: Swift does not support storing fields in the padding of the previous
fields just yet, so let's not import fields like that from C++.
Represent them as opaque blobs instead.
Issue: rdar://149072458
Risk: Low, the fix is targeted at a scenario that was crashing before.
Testing: Regression test added.
Original PR: #80786
Reviewer:
Explanation: One of the initializers were missing and the other was crashing at
runtime due to a faulty signature in the overlay.
Issue: rdar://149846666
Risk: Low, the fix is additive.
Testing: Regression test added.
Original PR: #81097
Reviewer:
Explanation: There was an inconsistency between non-const and const FRT
pointers. The former used Direct_Unowned the latter used Indirect
calling convention. We want to use Direct_Unowned for both cases. The
crash was the result of a calling convention mismatch between the
SILFunctionType of a Swift closure and the SILFunctionType of the C++
function's formal parameter that is taking a function pointer. The
compiler tried to insert a conversion between the two function types
that does not exist and caused an assertion in debug compilers and
miscompilation in production compilers.
Issue: rdar://149398905
Risk: Low, the fix is targeted and we change to a well-tested behavior
with non-const FRT pointers.
Testing: Regression test added.
Original PR: #81070
Reviewer: @j-hui
Add a case to LifetimeDependence.Scope to support dependencies on address-only
'let' variables. This comes up with C++ interop.
Fixes rdar://147500193 (Spurious lifetime error with closures)
(cherry picked from commit 5831777407)
Explanation: C++ templates are imported as Swift generics.
Unfortunately, the codegen for some of the instantiations will crash
codegen due to a confusion in how Swift pointer types are mapped back to their
native counterparts. As a result, when a user is passing an
UnsafePointer<Element>? to a C++ span constructor we got a crash. The
user should never need the generic version of the initializer as we
already have an initializer taking an UnsafePointer<Element> in the C++
overlay. This PR avoids importing the templated span constructors to
work around this issue.
Issue: rdar://148961349
Risk: Low, the fix is very targeted.
Testing: Regression test added.
Original PR: #81030
Reviewer: @j-hui
Explanation: C++ namespaces imported as Swift enums. This was not
accounted for in a condition and that resulted in not importing lifetime
annotations for functions that are in namespace scope. This PR fixes
that condition.
Issue: rdar://149756644
Risk: Low, the fix is very targeted.
Testing: Regression test added.
Original PR: #80986
Reviewer: @j-hui
Currently those operators are imported with a `consuming:` label, which isn't valid in Swift.
We could just remove the label from these parameters, but that introduces a source breakage due to name lookup ambiguity.
So, to avoid ambiguity, let's not import such operators into Swift.
rdar://149020099
(cherry picked from commit eb7adc794d)
Revert "Merge pull request #79707 from DougGregor/transparent-integer-conversions"
This reverts commit 9c2c4ea07f, reversing
changes made to 829e03c104.
When generating debug symbols for private Clang types (which we started
importing recently), the compiler crashes due to an assertion failure
from ClangModuleUnit::getDiscriminatorForPrivateDecl(), which is called
by getFilePrivateScope().
This patch fixes the issue crash by not calling getFilePrivateScope()
for Clang types. A discriminator is usually needed to disambiguate
private Swift types declared in different files, but Clang types follow
different scoping conventions that make this discriminator unnecessary.
rdar://148481025
(cherry picked from commit dd2f465025)
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
Explanation: In Swift, Escapable types cannot have non-escapable stored
properties. Unfortunately, these checks could be circumvented via C++
interop, constructing invalid Swift code. This patch errors out on
importing C++ code of this shape.
Issue: rdar://148899224
Risk: Low, the fix is fairly targeted to the affected scenario.
Testing: Added tests to test suite
Original PR: #80671
Reviewer: John Hui
We should not complain about usage of SWIFT_RETURNS_(UN)RETAINED for templated C++ APIs when instantiated with a non SWIFT_SHARED_REFERENCE types
rdar://143732201
Explanation: Fixes that functions imported from C++ namespaces are
taking a different code path than functions importing from the global
namespace. This also fixes an error where the return type of a templated
function is sometimes not imported.
Scope: C++ forward interop.
Issue: rdar://148735986
Risk: Low, the fix is targeted to make C++ functions in namespaces take
a well tested code path that we already use for C++ functions in the
global scope.
Testing: Added tests to test suite
Reviewer: John Hui
Explanation: Fixes a runtime crash in the generated binary due to
mismatched calling convention when calling a function taking an rvalue
reference.
Scope: Affects C++ APIs taking rvalue references to directly passed
types (e.g., trivially destructible types).
Issue: rdar://148585343
Risk: Low, targeted to rvalue references which is a newly supported
feature.
Testing: Added tests to test suite
Reviewer: John Hui
This patch fixes the access check for nested private C++ enums to look for the SWIFT_PRIVATE_FILEID of the enclosing C++ class, if any. Previously, the check was looking at for SWIFT_PRIVATE_FILEID on the enum decl itself (which is meaningless); that prevented nested private enum members from being accessible in Swift.
This patch also specializes the type signature of getPrivateFileIDAttrs to clarify the fact that SWIFT_PRIVATE_FILEID is not a meaningful annotation on anything other than CXXRecordDecl, because that is the only kind of decl that can assign access specifiers to its members.
rdar://148081340
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
* [Swiftify] Emit Mutable[Raw]Span when possible
Previously wrappers would use UnsafeMutable[Raw]Pointer for mutable
pointers, and Span for non-const std::span, to prevent the compiler from
complaining that MutableSpan didn't exist.
Now that MutableSpan has landed we can finally emit MutableSpan without
causing compilation errors. While we had (disabled) support for MutableSpan
syntax already, some unexpected semantic errors required additional
changes:
- Mutable[Raw]Span parameters need to be inout (for mutation)
- inout ~Escapable paramters need explicit lifetime annotations
- MutableSpan cannot be directly bitcast to std::span, because it is
~Copyable, so they need unwrapping to UnsafeMutableBufferPointer
rdar://147883022
* [Swiftify] Wrap if-expressions in Immediately Called Closures
When parameters in swiftified wrapper functions are nullable, we use
separate branches for the nil and nonnil cases, because
`withUnsafeBufferPointer` (and similar) cannot be called on nil.
If-expressions have some limitations on where they are allowed in the
grammar, and cannot be passed as arguments to a function. As such, when
the return value is also swiftified, we get an error when trying to
pass the if-expression to the UnsafeBufferPointer/Span constructor.
While it isn't pretty, the best way forward seems to be by wrapping the
if-expressions in Immediately Called Closures.
The closures have the side-effect of acting as a barrier for 'unsafe':
unsafe keywords outside the closure do not "reach" unsafe expressions
inside the closure. We therefore have to emit "unsafe" where unsafe
expressions are used, rather than just when returning.
rdar://148153063
This is a follow-up to d3e43bbe which resolved the issue for value types, but not for foreign reference types.
This change teaches IRGen that a base type of a C++ type might occupy less memory than its `sizeof`, specifically, it might only use `dsize` amount of memory.
rdar://147527755
Currently, we only get warnings for using unsafe types in expressions
but not in the function signature. The tests did not use the std::string
object in the function body. As a result, we regressed and std::string
was considered unsafe.
The reason is that the annotation only mode for calculating escapability
of a type did not do what we intended. std::basic_string is
conditionally escapable if the template argument is escapable. We
considered 'char' to have unknown escapability in annotation only mode.
The annotation only mode was introduced to avoid suddenly importing
certain types as not escapable when they have pointer fields and break
backward compatibility.
The solution is to make annotation only mode to still consider char and
co as escapable types and only fall back to unknown when the inference
otherwise would have deduced non-escapable (for unannotated typed).
