Previously, the lazily-created extensions used for globals imported as members of a type used the lazy module loader, but `ClangImporter::Implementation::loadNamedMembers()` didn’t actually work for them. Other parts of the compiler instead contrived to avoid loading these members by name by forcing all members to load before any selective loading might occur.
This commit modifies that code path to accommodate extensions with no matching clang node, which is how these are represented. With this change, other parts of the compiler can unconditionally use the `LazyMemberLoader` whenever it is present.
There may be performance improvements from this change, but I don’t expect any functional changes.
For C++ types that are defined in the bridging header, or are `#include`-d from the bridging header, we did not generate the automatic conformances to `CxxSequence`, `CxxRandomAccessCollection` protocols.
To check whether we should try to conform a C++ type to those protocols, the compiler checks for the presence of `requires cplusplus` in the module declaration in a modulemap file. This check is there to prevent us from accidentally pulling in `Cxx`/`CxxStdlib` modules when a client is importing a C library.
This change makes sure those conformances are generated.
rdar://121927459
Don't delete the OS declaration of `exit` because the concurrency shims aren't always imported, and so the shim declaration might not always be available.
Don't override the OS declaration of `exit` in the concurrency shims since we can't just delete the OS one. Instead, set up internal shims just for building Concurrency that forward declares `exit`.
If the C++ type of a function parameter defines a custom copy constructor, assume that it is safe to use from Swift. This matches the heuristic that we use to detect if a C++ method is safe based on the return type.
rdar://121391798
This makes sure we print `= cxxDefaultArg` for parameters that have a default expression on the C++ side.
Note that we can't run the safety heuristic that we use during normal compilation, since we don't know all of the types involved.
rdar://121440191
Prior to emission of `.d` and `.swiftdeps` outputs. In implicit builds such dependencies are registered during the construction of the corresponding Clang module by the ClangImporter's built-in Compiler Instance. In explicit builds, since we load pre-built PCMs directly, we do not get to do so. So instead, manually register all `.h` inputs of Clang module dependnecies.
Resolves rdar://121354886
It should be the responsibility of callers to map the type to a
contextual type, as needed. When it's not possible or repetitive to do
so, there is a special-purpose function `isInterfaceTypeNoncopyable` for
Sema.
"-opaque-pointers" has not been a valid clang cc1 argument for a long time
since it is the default. What is even worst is that clang is treating
that out of date option as "-o paque-pointers" and return no error.
Fortunately, ClangImport doesn't write anything to output file,
otherwise it is going directly to this "paque-pointers" file.
This is required to make the compiler distinguish between instantiations of `std::function`.
Previously, when generating a Swift type name for a `std::function` instantiation, we would always emit `_` as the template parameter. If someone referenced two different instantiations of `std::function` in a Swift module, they would get mangled with the same name, triggering linker errors later.
rdar://103979602
Under a set of circumstances that I cannot fully characterize, it was possible for `ClangImporter::Implementation::importDeclContextOf()` to end up recursing until stack overflow while trying to import a global as a member.
The cycle was caused by `addExtension()` using a newly-created extension’s lazy member loader to load its members before the extension had been added to ClangImporter’s `extensionPoints` table. Loading the members would try to import the IAM members again, which would cause `importDeclContextOf()` to try to create another extension to contain them, which `addExtension()` would force to load those members. Repeat until stack overflow.
I have fixed this bug by registering the extension in the `extensionPoints` map before its member loader is set. This ensures that if `importDeclContextOf()` gets called for any reason after that point, it will return the existing extension instead of creating a new one, avoiding the cycle.
Unfortunately, I was not able to figure out the exact conditions that were necessary to reproduce this bug, so I have not included a test. However, I have tested with the affected project locally and confirmed that this change lets it build. All existing tests pass.
Fixes rdar://120854030.
