AppKit defines certain constants in Objective-C, and then renames them into different constants in Swift, e.g. `NSUpArrowFunctionKey` is renamed into `NSEvent.SpecialKey.upArrow.rawValue`.
In addition to that, AppKit also re-defines these constants in pure-Swift, which isn't the intended mechanism for renaming such constants.
Prior to https://github.com/llvm/llvm-project/pull/145947, Clang was silently dropping the `SwiftName` API Notes attributes on these constants due to a bug in the name validation mechanism. Clients of AppKit relied on that behavior and continued to use the old spelling in Swift. To preserve source compatibility and avoid a deprecation error, let's continue dropping the `SwiftName` attribute on select constants from AppKit.
rdar://157485334
This teaches ClangImporter to import C++ decls that are declared within `extern "C" { ... }`/`extern "C++" { ... }` blocks which are nested in namespaces.
rdar://139067788
In case the type does not define a type alias with the same name fall
back to the default type of the associated type in the protocol.
Previously, the compiler crashed.
Unfortunately, we are still crashing when we do not find the right
conformance. In a follow-up PR I plan to add more graceful handling of
the case when the lookup fails.
rdar://154098495
If a C++ struct is annotated with `__attribute__((swift_attr("~Copyable")))`, Swift should not try to instantiate the copy constructor of the struct. This provides an escape hatch for C++ types that are designed to be non-copyable, but do not explicitly define a deleted copy constructor, and instead trigger complex template instantiation failures when a copy is attempted.
rdar://157034491
This unblocks the CI while we figure out some SILGen issues. We cannot
reuse AddressableParameters because that is already used in some
projects and consuming modules where the AddressableParameters flag was not
propagated to results in deserialization errors.
When we cannot respect the "destroy:" annotation, mark the type as
deprecated with a message thst says why there is a problem. There are
various potential problems:
* Multiple conflicting destroy functions
* Destroy functions that don't meet the pattern
* Type isn't imported as a move-only type
* Type has a non-trivial destructor (in C++)
A C struct can be imported as noncopyable, but C doesn't have
destructors, so there is no way to provide user-defined logic to
perform the destruction. Introduce a new swift_attr that applies to
imported noncopyable types and which provides such a "destroy"
operation. It can be used like this:
typedef struct __attribute__((swift_attr("~Copyable")))
__attribute__((swift_attr("destroy:wgpuAdapterInfoFreeMembers")))
WGPUAdapterInfo { /*...*/ } WGPUAdapterInfo;
void wgpuAdapterInfoFreeMembers(WGPUAdapterInfo adapterInfo);
This will bring the WGPUAdapterInfo struct in as a noncopyable type
that will be cleaned up by calling wgpuAdapterInfoFreeMembers once it
is no longer in use.
Implements rdar://156889370.
This was behind a feature flag. Unfortunately, this flag is viral, if
the module we consume and the consuming module had inconsistent settings
that could lead to deserialization errors. To avoid this, we need to
move this out of the flag and apply the attribute unconditionally. This
PR moves addressable-self out of the experimental flag and addresses a
couple of the fallouts:
* This attribute should not be applied to types with reference semantics
like foreign reference types or Obj-C classes.
* There was a SILGen assertion failure which is solved by pealing off
the @lvalue specifier from the type behind a load expression.
This fixes part of rdar://155971658
We already make imported computed properties' setters private in
VisitFieldDecl(), but not in VisitIndirectFieldDecl(), which handles
things like the members of an anonymous union in another struct.
Controlled from Swift with '-version-independent-apinotes', which, for the underlying Clang invocation enables '-fswift-version-independent-apinotes', results in PCMs which aggregate all versioned APINotes wrapped in a 'SwiftVersionedAttr', with the intent to have the client pick and apply only those that match its current Swift version, discarding the rest.
This change introduces the configuration flags for this mode as well as the corresponding logic at the beginning of `importDeclImpl` to canonicalize versioned attributes, i.e. select the appropriate attributes for the current target and discard the rest.
The code for handling Swift conforms_to attributes was specific to
C++ record types. Generalize it to work on typedefs imported as
nominal types, also in C.
Fixes rdar://156290361.
Normally, Swift cannot import an incomplete type. However, when we are
importing a SWIFT_SHARED_REFERENCE type, we're always dealing with
pointers to the type, and there is no need for the underlying type to
be complete. This permits a common pattern in C libraries where the
actual underlying storage is opaque and all APIs traffic in the
pointer, e.g.,
typedef struct MyTypeImpl *MyType;
void MyTypeRetain(MyType ptr);
void MyTypeRelease(MyType ptr);
to use SWIFT_SHARED_REFERENCE to import such types as foreign
references, rather than as OpaquePointer.
Fixes rdar://155970441.
Unfortunately, addressable parameters are viral, the whole dependency
chain needs to be consistent otherwise we get deserialization errors
when loading a module. The solution is to universally enable addressable
parameters for C++ interop but there are some blockers at the moment
that need to be solved first. Temporarily revert these changes until
those blockers are resolved.
This reverts commit b00ff4568b, reversing
changes made to 396379ecbf.
