Swift validates the retain/release operations for foreign reference types to check for obvious errors, e.g. a wrong parameter type or return type.
That logic was only running for C++ foreign reference types. This patch enables it for C foreign reference types as well.
rdar://158609723
After #83289 and #82879 landed we should no longer get deserialization
failures and this feature is no longer behind a flag. This patch also
changes how we query if a function's return value depends on self.
Previously, we queried the lifetime dependencies from the Swift
declaration. Unfortunately, this is problematic as we might have not
finished fully importing the types in the function signature just yet
and the compiler might end up populating the conformance tables
prematurely. To work this around, I store functions with self-dependent
return values where lifetimes are computed in the importer for later
use.
The PR also adds a test to make sure the addressable dependency feature
will not result in deserialization errors.
rdar://155319311&154213694&112690482&128293252
Release/retain functions for C++ foreign reference types might return a reference count as an integer value.
Swift previously emitted an error for such functions, saying that the retain/release functions need to return void or a reference to the value.
rdar://157853183
Afteri #83712 landed, let's make another try enabling addressable
parameters by default.
This reverts commit 61d60eb6ad, reversing
changes made to 670f69eadc.
When inheriting constructors, we define the inherited ctors in the
derived class. We should not do that for copy and move operations as
these operations can never be invoked (the implicit/defined/deleted ctor
in the derived class always takes precedence). This fixes an issue where
the lifetime parameters are not getting inferred for these spurious
constructor definitions. This should also save us from doing some
redundant work in the importer. Fixes#82183.
rdar://153081347
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
