A recent refactoring uncovered two places where we could end up
importing a C++ field declaration as a property more than once:
1. Importing the declaration context of a field in C++ mode can then
go import all of the fields. In such a case, check that the field
we're importing didn't happen already, and bail out early if it did.
This is common practice in the Clang importer but wasn't happening here.
2. One caller to the function that imported a field from a C++ base
class into its inheriting class (as a computed property) wasn't
checking the cache, and therefore created a redundant version.
Fix both issues.
When importing a C header in the C++ language mode, Clang/Swift treat C structs as C++ structs.
Currently Swift synthesizes a default initializer that zero-initializes the backing memory of the struct for C structs, but not for C++ structs.
This is causing issues in existing projects that use C libraries and rely on having the default initializer available in Swift. This change enables the synthesis of a default initializer for C++ structs. Since many C++ structs are not designed to be initialized this way, the initializer is marked as deprecated in Swift.
rdar://109727620
The lookup to resolve an ObjC forward declaration
to its potential native Swift definition within
a mixed module is becoming cyclic somehow.
The old uncached lookup still works, so it seems
this is an issue with cache invalidation somehow.
Until the route of the issue, use the old uncached
lookup method.
If two different C++ structs have methods with the same name, both annotated with `SWIFT_COMPUTED_PROPERTY`, ClangImporter previously confused them when one of the structs referenced the other struct.
rdar://108990490 / resolves https://github.com/apple/swift/issues/65675
A record that's non trivia for purpose of calls, as defined in Itanium ABI is allowed to have non-trivial copy/move assignment operators, but it most not have non-trivial constructors or destructors. This change ensures that a C++ record with a non-trivial copy assignment operator but trivial other members can be passed/returned directly by value, so that the compiler can accept the returned value correctly when calling a C++ function.
Calling getImportedModules requires to list the desired kind of imports.
With the new kind of imports this has become cumbersome. Let's simplify
it by offering common sets of imports. Advanced call sites can still
list the desired imports explicitly.
This modifies the ClangImporter to introduce an opaque placeholder
representation for forward declared Objective-C interfaces and
protocols when imported into Swift.
In the compiler, the new functionality is hidden behind a frontend
flag -enable-import-objc-forward-declarations, and is on by default
for language mode >6.
The feature is disabled entirely in LLDB expression evaluation / Swift
REPL, regardless of language version.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::optional` when used from Swift code.
As of now, the overlay adds an initializer of `Swift.Optional` that takes an instance of `CxxOptional` as a parameter.
At the call sites of `findAnonymousEnumForTypedef` we often wish to
import the returned enum declaration and return the type the declaration
creates.
Prior to this patch, we assumed that the enum declaration would be
imported as a `NominalTypeDecl`. This is not always the case. For
whatever reason, sometimes in typechecking we import a declaration
for various different naming versions. If the Swift name for an imported
enum differs between the canonical name version, and currently
requested name version, we import the enum as a `TypeAliasDecl` instead.
Prior to this patch, this meant we would hit asserts importing some
components of UIKit.
This patch relaxes the assumption that the import is a `NominalTypeDecl`
to just a `TypeDecl`, which as of yet, seems to be true.
If a C++ struct defines multiple overloads of `operator*`, avoid synthesizing multiple `var pointee: Pointee` properties, since that would introduce name resolution ambiguity. Instead, pick one of the const overloads and synthesize a single `pointee` property.
This is required for `std::optional` support.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::map` and `std::unordered_map` when used from Swift code.
As of now, `CxxDictionary` adds a subscript with an optional return type that mimics the subscript of `Swift.Dictionary`.
Similar to https://github.com/apple/swift/pull/63244.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::set`, `std::unordered_set` and `std::multiset` when used from Swift code.
As of now, `CxxSet` adds a `contains` function to C++ sets.
C++ stdlib set types are automatically conformed to `CxxSet`: `std::set`, `unordered_set`, `std::multiset`. Custom user types are not conformed to `CxxSet` automatically: while a custom type might have an interface similar to `std::set`, the semantics might differ, and adding a conformance would cause confusion.
