We were only previously doing this check when we had a typedef,
because that is the scenario where we encountered this issue.
This patch moves the check closer to where we would actually instantiate
the template, so that these cases can be stopped in more situations.
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
This is a small incremental patch that is designed to address the issue
discovered by 9aa3c5d17c, which is that we
are importing various Decls multiple times.
rdar://164616956
This attribute introduces some conversions between the annotated smart
pointer type and the native swift reference type. In the future we plan
to introduce bridging so the smart pointer type can be hidden in the
signature and we can automatically convert it to the native Swift
reference type on the ABI boundaries.
This PR is using a new way to use swift_attr attributes. Instead of
doing the parsing in the clang importer it falls back to Swift's
attribute parsing and makes sure that the annotation has valid Swift
attribute syntax.
rdar://156521316
This fixes an assertion failure in ClangImporter that was blocking bootstrapping of the FreeBSD toolchain.
Iterators pointing into `Impl.GetterSetterMap[result]` were being invalidated inside of the for-each loop.
I was unable to minimize the reproducer, so this doesn't include a test case.
rdar://164518108
This introduces support for converting a Swift closure that captures variables from its surrounding context into an instance of `std::function`, which is useful for working with C++ APIs that use callbacks.
Each instantiation of `std::function` gets a synthesized Swift constructor that takes a Swift closure. Unlike the previous implementation, the closure is _not_ marked as `@convention(c)`. The body of the constructor is created lazily.
Under the hood, the closure is bitcast to a pair of a function pointer and a context pointer, which are then wrapped in a C++ object, `__SwiftFunctionWrapper`, that manages the lifetime of the context object via calls to `swift_retain`/`swift_release` from the copy constructor and the destructor. The `__SwiftFunctionWrapper` class is templated, and is instantiated by ClangImporter.
rdar://133777029
This won't affect diagnostic printing, as the diagnostic engine checks
the GeneratedSourceInfoKind and stops expanding if it's an
AttributeFromClang kind. This helps the diagnostic verifier expand to
the original location in source code however.
If we try to import this in ObjC interop mode:
```objc
typedef CF_OPTIONS(uint32_t, MyFlags) {
...
} CF_SWIFT_NAME(MyCtx.Flags);
struct MyStruct {
MyFlags flags;
...
} CF_SWIFT_NAME(MyCtx);
```
ClangImporter tries to import `MyCtx/MyStruct` before it imports
`MyFlags` (via `importDeclContextOf()`), which in turn tries to import
`MyFlags` again due to the `flags` field. The existing cycle-breaking
mechanism prevents us from looping infinitely, but leads us to import
two copies of the Swift `EnumDecl`, which can cause errors later during
CodeGen.
~~This patch adds an assertion to catch such issues earlier, and breaks
the cycle by checking the cache again.~~ This patch no longer does so
because that caused issues beyond the scope of this patch.
rdar://162317760
This patch re-arranges the implementation of importFunctionDecl() to
delay side-effectful logic as late as possible, to avoid importing or
allocating parts of the AST that we do not need.
[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
...with bounds attributes
This creates safe overloads for any methods in the protocol annotated
with bounds information. Updates _SwiftifyImportProtocol to make the
added overloads in the protocol public.
rdar://144335990
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.
