[cxx-interop] Make ClangDeclExplicitSafety request non-recursive
[cxx-interop] Do not import template type arguments
[cxx-interop] Check template argument safety in ClangDeclExplicitSafety
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.
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
Expressed as `__swift_attr__("~Sendable")` this acts like `: ~Sendable`
on Swift type declarations and supersedes `@_nonSendable(_assumed)`.
Resolves: rdar://140928937
This code doesn't interact that much with the rest of ClangImporter, and
will continue to grow. Keeping it in a separate file makes it easier to
navigate.
Checking this upon import was overlooking annotations that explicitly
mark a type as safe (or unsafe). Instead, we consolidate this logic in
the ClangDeclExplicitSafety request.
rdar://163196609
We currently do not have sound enforcement of exclusivity in those cases
regardless of mutability. Let's not generate these methods for now until
we figure out how to make them safer.
rdar://163068618
Introduce `DeclAttribute::attachToDecl` which is the now the main
entry point for associating an attribute with a decl. Different
attributes can implement `attachToDeclImpl` to add their custom logic.
Move DifferentiableAttr, DerivativeAttr, CustomAttr, and ABIAttr over
to this new logic.
Doing so preserves ClangImporter's behavior first introduced in
f12b48aa86, but do so without relying on
importing the type argument (since that can lead to template
over-instantiation).
This patch also promotes the logic of hasUnsafeType() to a standalone
SimpleRequest, to provide a QualType-typed entry point for evaluating
the safety of a Clang entity.
_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
