_SwiftifyImport assumes types like Swift.Int, Swift.UnsafePointer<T> and
Swift.Span<T> are available. This is not the case when building the
stdlib itself. Disable safe interop in the stdlib to prevent errors.
This currently has no effect, but will when this feature is enabled by
default, which I have manually tested.
Prior to this patch, we eagerly imported template type arguments.
A consequence of doing so is that we over-instantiate (potentially
unused) type arguments, which causes unnecessary errors.
The only apparent use we have for these type arguments are to check
whether they are unsafe, so that we can mark the instantiated type as
unsafe as well... even if the instantiated type does not use its unsafe
template type argument at all.
Note that using un-instantiatable types in template type arguments is
supported in C++. The test case included in this patch validates this
behavior, for both missing member and incomplete type errors.
Note, also, that as of this patch, dumping the module interface of
CxxModule actually causes swift-ide-test to emit compiler errors, since
it tries to instantiate the invalid types MissingMember<Empty> and
IncompleteField<Incomplete>. However, these errors are simply swallowed
by swift-ide-test, so they should be harmless, though we should probably
get rid of them entirely in future work.
rdar://145238539
Introduce CustomAttrOwner that can store either a Decl for an
attached attribute, or a DeclContext for e.g a type or closure
attribute. Store this on CustomAttr such that we can query it from
the name lookup requests.
`registerStdSpanTypeMapping` used to be a lambda inside `swiftify`.
By moving it, along with the `typeMapping` state, inside
`SwiftifyInfoPrinter` we will simplify changes necessary to support
`_SwiftifyImportProtocol` in ClangImporter.
Swift cannot guarantee exclusivity of a class. On the other hand,
lifetimebound annotations on the C++ side do not guarantee exclusivity.
To resolve this issue, we ignore lifetime dependency annotations that
introduce exclusive dependence on classes and import functions with ignored
annotations as unsafe. Currently, Swift has no language feature to
support these scenarios but it might get new features in the future to
help people work around this problem.
rdar://153747746
The overload resolution generated a constraint that tried to bind
outer.inline_inner to outer. This constraint failed. This PR attempts to
recognize this scenario and make the constraint succeed.
rdar://158401346
`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
While we handled prepending & to MutableSpan parameters, regular
parameters that were unchanged during the transformation were not
checked for inout-ness.
Swift crashes when importing C++ typedefs to forward-declared explicit
template specializations. In assert build we see this assertion failure
happening in clang:
`Assertion failed: (!T->isDependentType() && "should not see dependent
types here"), function getTypeInfoImpl, file TypeNodes.inc, line 79.`
Example that crashes:
```cpp
template <typename T> struct MyTemplate { T value; };
template <> struct MyTemplate<int>; // Forward-declared specialization
typedef MyTemplate<int> MyIntTemplate;
```
In this patch, I propose detecting forward-declared explicit
specializations in typedef imports. Instead of crashing, these
specializations should be blocked from being imported with a diagnostic
similar to the forward declared (but not defined) structs.
rdar://147595723
An old piece of logic in ClangImporter was trying to limit the number of instantiations for each C++ class template to prevent long compile times. Unfortunately this started causing hard-to-reproduce deserialization errors on large projects which use many different instantiations of `std::vector` and `std::allocator`.
The instantiation limit was arbitrary, it serves no real purpose and causes issues. This change removes it.
rdar://158397914
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
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
