When Swift imports C structs, it synthesizes an initializer that takes no arguments and zero-initializes the C struct.
When C++ interop is enabled, Clang treats all C structs as if they were C++ structs. This means that some of the C structs will get a default constructor implicitly generated by Clang. This implicit default constructor will not zero-initialize trivial fields of the struct.
This is a common source of confusion and subtle bugs for developers who try to enable C++ interop in existing projects that use C interop and rely on zero-initialization of C structs.
rdar://115909532
When a default constructor is declared, but does not have a body because it is defaulted (`= default;`), Swift did not emit the IR for it. This was causing linker error for types such as `std::map` in libstdc++ when someone tried to initialize such types from Swift.
rdar://110638499 / resolves https://github.com/apple/swift/issues/61412
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
If possible, add imported members to the StructDecl's LookupTable rather than adding them directly as members. This will fix the issues with ordering that #39436 poorly attempted to solve during IRGen.
This also allows us to break out most of the test changes from #39436.
* Check isAggregate instead of hasUserDeclaredConstructor.
* Rename addEmptyArgNamesForCxxFunc -> addEmptyArgNamesForClangFunction.
* Other minor fixes and cleanups.
- Adapt tests to changes that have happened in the meantime (e.g.
`HasVirtualBase` is rightly no longer considered loadable)
- Don't import copy or move constructors (noticed this because
references are now imported correctly, so copy and move constructors
suddenly started showing up in the SIL test)
- Don't try to define an implicitly-deleted default constructor (this
previously broke loadable-types-silgen.swift)
