Conflicts:
lib/Basic/Platform.cpp
```
diff --git a/lib/Basic/Platform.cpp b/lib/Basic/Platform.cpp
index 240edfa144a..1797c87635f 100644
--- a/lib/Basic/Platform.cpp
+++ b/lib/Basic/Platform.cpp
@@ -200,10 +200,7 @@ StringRef swift::getPlatformNameForTriple(const llvm::Triple &triple) {
case llvm::Triple::CUDA:
case llvm::Triple::DragonFly:
case llvm::Triple::DriverKit:
-<<<<<<< HEAD
case llvm::Triple::ELFIAMCU:
-=======
->>>>>>> main
case llvm::Triple::Emscripten:
case llvm::Triple::Fuchsia:
case llvm::Triple::HermitCore:
```
In libstdc++13 on Ubuntu 23.10 the type `std::tzdb` is non-copyable but does not explicitly delete its copy constructor. It instead triggers template instantiation errors when trying to use the copy constructor. This is problematic for Swift, since we try to instantiate copy constructors for most C++ types we import.
This disables the import of `std::tzdb` to unblock nightly toolchains for Ubuntu 23.10 until we come up with a better solution.
rdar://126486849 / https://github.com/apple/swift/issues/73037
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
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.
