This fixes a crash in SILGen when calling a C++ subscript that has an unnamed parameter from Swift.
The parameters from a C++ `operator[]` get carried over to the synthesized Swift subscript. If the Swift parameter has no name, there is no way to refer to it in SIL. However, the synthesized subscript accessor needs to pass this parameter to C++.
This change makes sure that we give a name to the Swift parameter if there isn't already a name on the C++ side.
rdar://83163841
CountAttributedType and TypeCoupledDeclRefInfo are new Clang type
and type metadata created for types with the 'counted_by' attribute
that shouldn't be accessible from Swift right now. Hence, marking
them unreachable.
C++ pointer type `T*` is generally imported as `Unsafe(Mutable)Pointer<T>`. However, if `T` is non-copyable in Swift (e.g. it has a deleted C++ copy constructor), using `UnsafePointer<T>` type requires noncopyable generics to be enabled.
This was causing assertion failures when building SwiftCompilerSources in https://github.com/apple/swift/pull/72912.
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
The binary module built from a CAS build will have the embeded bridging
header info with 0 modTime. Allow a regular build to import such a
module with the same behavior as if the module is built from a regular
build.
rdar://126221616
When caching is enabled with include-tree, the bridging header PCH is
created from the include tree directly. Setup the rewriter correctly
when embedding the bridging header into swift binary module.
rdar://125719747
This fixes -gmodules when caching by adopting the new clang -cc1 option
-finclude-tree-preserve-pch-path. -gmodules is required to make
debugging work when examining types that come from clang modules or
bridging headers, but was previously being disabled by clang's caching
support.
rdar://126370706
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 gearing up to move to `std::endianness` and as part of that has
moved `llvm::support::endianness` to `llvm::endianness`
(bbdbcd83e6702f314d147a680247058a899ba261). Rename our uses.
Clang is using C++17 standard version by default since Clang 16.
Swift’s ClangImporter should do the same, to make sure that clients who run clang and then swiftc without explicit std version see consistent behavior.
rdar://125777068
