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.
Cover all va_list family of types just aliased by __builtin_va_list, including __isoc_va_list from wasi-libc. This enables proper C interop for variable argument functions on WASI targets.
Close https://github.com/swiftlang/swift/issues/72398
This fixes modularization errors that arise when importing a C++ header that contains `#include <guiddef.h>`, which might hijack this header from the WinSDK module where it belongs.
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
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
Cache the result of turning a `ValueDecl` into an `AvailabilityDomain`. Use
split caching to make the common case of the decl not representing an
availability domain efficient.
NFC.
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
Whenever we have a vector type, the escpability depends on the
escapability of the element type. This will enable us to consider more
types like std::vector<simd::float3> as safe by default.
rdar://157141552
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
This teaches ClangImporter to import C++ decls that are declared within `extern "C" { ... }`/`extern "C++" { ... }` blocks which are nested in namespaces.
rdar://139067788
