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: Fix a compilation error in the generated reverse interop
header when a nested foreign type is used in a generic context and it is
reexposed to C++.
Issue: rdar://148597079
Risk: Low, the fix is fairly targeted to the affected scenario.
Testing: Added tests to test suite
Reviewer: @egorzhdan
Explanation: Fixes an issue where the generated reverse interop header
would not compile for nested classes when library evolution is turned
off.
Scope: C++ reverse interop for nested classes for non-opaque types.
Issue: rdar://147882976
Risk: Low, the fix is fairly targeted. While it does affect other
(non-nested type) scenarios, those changes are fairly straightforward
making some names fully qualified. Moreover, that is well tested in our
test suite.
Testing: Added tests to test suite
Reviewer: @egorzhdan
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
__counted_by already had MutableSpan support, so add it for std::span
for parity. But since MutableSpan hasn't landed in the standard library
yet, disable emitting it to prevent compilation errors in expansions.
rdar://147882736
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).
Print the type traits in reverse interop to enable the use of foreign
reference type in generics like Swift arrays. Also make sure optional
foreign reference types can be passed around as raw pointers.
rdar://108139769
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
When importing C++ decls in symbolic mode, class templates are not instantiated, which means they might not have a destructor or a move constructor. Make sure we are not trying to diagnose those missing lifetime operations in symbolic mode.
This fixes incorrect diagnostics that were emitted during indexing at the end of compilation:
```
warning: 'import_owned' Swift attribute ignored on type 'basic_string': type is not copyable or destructible
```
As a nice side effect, this moves the logic that emits these diagnostics from the request body, which might be invoked many times, to the importer itself, which is only invoked once per C++ class.
rdar://147421710
This fixes a compiler bug that got exposed by f11abac652.
If a C++ type is declared in a nested Clang submodule, Swift was emitting errors that look like:
```
Type alias 'string' is not available due to missing import of defining module 'fwd’
```
rdar://146899125
