LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
If an imported type's conformance cannot be implicitly inferred, allow
it to be explicitly stated via
`__attribute__((__swift_attr__("_BitwiseCopyable")))`.
This adds a new implementation of virtual method dispatch that handles reference types correctly.
Previously, for all C++ types an invocation of a virtual method would actually get dispatched statically. For value types this is expected and matches what C++ does because of slicing. For reference types, however, this is incorrect, we should do dynamic dispatch.
rdar://123852577
These constants could be used with observer APIs from a different isolation
context, so it's more convenient to import them as `nonisolated` unless
they are explicitly isolated to a MainActor.
Resolves: rdar://114052705
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`.
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
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.
`clangSema.isCompleteType` checks for decl visibility according to the module visibility rules, which we don't actually need. What we need to check is whether the record has a definition – this is the check we already use elsewhere in ClangImporter.
This makes sure that we can import `std::function` on Windows.
rdar://103979602
Clang rejects code that tries to call a constructor of an abstract C++ class with an error: "Variable type 'Base' is an abstract class". Swift should reject this as well.
rdar://119689243
libc++ recently split the `std` module into many top-level modules: 571178a21a
Previously if a C++ module had `#include <iosfwd>`, importing that module in Swift would make the entire C++ stdlib visible from Swift, since it was a single top-level Clang module. After libc++ got split it doesn't automatically do so, but we need to preserve the current behavior for Swift users.
rdar://119270491
