Merge pull request #4729 from swiftwasm/main

[pull] swiftwasm from main

Author: kateinoigakukun

SwiftCompilerSources/CMakeLists.txt

@@ -237,16 +237,16 @@ else()
     COMMAND
         "sed"
         -n -e "/header/!d" -e "s/.*header/#include/" -e "w ${CMAKE_CURRENT_BINARY_DIR}/HeaderDependencies.cpp"
-        "${CMAKE_SOURCE_DIR}/include/swift/module.modulemap"
-    DEPENDS "${CMAKE_SOURCE_DIR}/include/swift/module.modulemap"
+        "${CMAKE_CURRENT_SOURCE_DIR}/../include/swift/module.modulemap"
+    DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/../include/swift/module.modulemap"
     COMMENT "Generate HeaderDependencies.cpp"
 )
 
   # step 2: build a library containing that source file. This library depends on all the included header files.
   #         The swift modules can now depend on that target.
   #         Note that this library is unused, i.e. not linked to anything.   
   add_library(importedHeaderDependencies "${CMAKE_CURRENT_BINARY_DIR}/HeaderDependencies.cpp")
-  target_include_directories(importedHeaderDependencies PRIVATE "${CMAKE_SOURCE_DIR}/include/swift")
+  target_include_directories(importedHeaderDependencies PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}/../include/swift")
 
   if(${BOOTSTRAPPING_MODE} MATCHES "HOSTTOOLS|CROSSCOMPILE")
 
@@ -295,6 +295,8 @@ else()
       set(compatibility_libs
           "swiftCompatibility50-${platform}"
           "swiftCompatibility51-${platform}"
+          "swiftCompatibility56-${platform}"
+          "swiftCompatibilityConcurrency-${platform}"
           "swiftCompatibilityDynamicReplacements-${platform}")
 
       list(APPEND b0_deps ${compatibility_libs})

benchmark/cmake/modules/AddSwiftBenchmarkSuite.cmake

@@ -106,7 +106,7 @@ endmacro()
 
 macro(configure_sdks_darwin)
   set(macosx_arch "x86_64" "arm64")
-  set(iphoneos_arch "arm64" "arm64e" "armv7")
+  set(iphoneos_arch "arm64" "arm64e")
   set(appletvos_arch "arm64")
   set(watchos_arch "armv7k" "arm64_32")
 

cmake/modules/DarwinSDKs.cmake

@@ -3,8 +3,8 @@ option(SWIFT_ENABLE_IOS32
        TRUE)
 
 if(SWIFT_ENABLE_IOS32)
-set(SUPPORTED_IOS_ARCHS "armv7;armv7s;arm64;arm64e")
-set(SUPPORTED_IOS_SIMULATOR_ARCHS "i386;x86_64;arm64")
+set(SUPPORTED_IOS_ARCHS "arm64;arm64e")
+set(SUPPORTED_IOS_SIMULATOR_ARCHS "x86_64;arm64")
 else()
 set(SUPPORTED_IOS_ARCHS "arm64;arm64e")
 set(SUPPORTED_IOS_SIMULATOR_ARCHS "x86_64;arm64")

cmake/modules/SwiftConfigureSDK.cmake

@@ -86,10 +86,6 @@ function(remove_sdk_unsupported_archs name os sdk_path architectures_var)
   foreach(arch ${${architectures_var}})
     if(sdk_supported_archs MATCHES "${arch}\n")
       list(APPEND architectures ${arch})
-    elseif(arch MATCHES "^armv7(s)?$" AND os STREQUAL "iphoneos")
-      # 32-bit iOS is not listed explicitly in SDK settings.
-      message(STATUS "Assuming ${name} SDK at ${sdk_path} supports architecture ${arch}")
-      list(APPEND architectures ${arch})
     elseif(arch STREQUAL "i386" AND os STREQUAL "iphonesimulator")
       # 32-bit iOS simulator is not listed explicitly in SDK settings.
       message(STATUS "Assuming ${name} SDK at ${sdk_path} supports architecture ${arch}")

docs/CppInteroperability/CppInteroperabilityStatus.md

@@ -154,17 +154,25 @@ This status table describes which of the following Swift language features have
 | Copy and destroy semantics     | Yes                                                      |
 | Initializers                   | Partially, as static `init` methods. No failable support |
 
+**Class types**
+
+| **Swift Language Feature**     | **Implemented Experimental Support For Using It In C++** |
+|--------------------------------|----------------------------------------------------------|
+| Class reference values         | Yes                                                      |
+| ARC semantics                  | Yes (C++ copy constructor,assignment operator, destructor perform ARC operations)  |
+| Initializers                   | No |
+
 **Methods**
 
 | **Swift Language Feature**     | **Implemented Experimental Support For Using It In C++** |
 |--------------------------------|----------------------------------------------------------|
-| Instance methods               | Yes, for structs only                                    |
+| Instance methods               | Yes, for structs and classes only                                    |
 | Static methods                 | No                                                       |
 
 **Properties**
 
 | **Swift Language Feature**     | **Implemented Experimental Support For Using It In C++** |
 |--------------------------------|----------------------------------------------------------|
-| Getter accessors               | Yes, via `get<name>`. Boolean properties that start with `is` or `has` are remapped directly to a getter method using their original name. For structs only                   |
-| Setter accessors               | Yes, via `set<name>`. For structs only                   |
+| Getter accessors               | Yes, via `get<name>`. Boolean properties that start with `is` or `has` are remapped directly to a getter method using their original name. For structs and classes only                   |
+| Setter accessors               | Yes, via `set<name>`. For structs and classes only                   |
 | Mutation accessors             | No                                                       |

docs/CppInteroperability/SwiftTypeRepresentationInC++.md

@@ -0,0 +1,124 @@
+# Swift Type Representation In C++
+
+This document describes in details how Swift types are represented in C++.
+It also covers related topics, like debug info representation for Swift types in
+C++.
+
+## Type Categories
+
+### Value Types
+
+1) Primitive Swift types like `Int`, `Float` , `OpaquePointer`, `UnsafePointer<int>?` are mapped to primitive C++ types. `int` , `float`, `void *`, int `* _Nullable` .
+
+* Debug info: Does C++ debug info suffices?
+
+2) Non-resilient fixed-layout Swift value type, e.g. `String` is mapped to a C++ class that stores the value in opaque buffer inline, e.g.:
+
+```c++
+class swift::String {
+  ...
+  alignas(8) char buffer[24]; // Swift value is stored here.
+}
+```
+
+* Debug info: ...
+
+
+3) Resilient (or opaque layout) inline-allocated Swift value type small enough to fit into inline buffer. e.g `URL` is mapped to a C++ class that stores the value in opaque buffer inline, e.g.:
+
+```c++
+class Foundation::URL {
+  ...
+  union {
+    alignas(8) char buffer[8]; // Swift value is stored here.
+    void *resilientPtr;
+  };
+};
+```
+
+* Debug info: ...
+
+
+4) Resilient (or opaque layout) boxed Swift value , e.g. `SHA256` is mapped to a C++ class that stores the value boxed up on the heap, e.g.:
+
+```c++
+class CryptoKit::SHA256 {
+  ...
+  union {
+    alignas(8) char buffer[8]; 
+    void *resilientPtr;        // Swift value is stored on the heap pointed by this pointer.
+  };
+};
+```
+
+* Debug info: ...
+
+
+5) Generic non-resilient fixed-layout Swift value type, e.g. `Array<Int>`, `String?`, is mapped to a C++ class that stores the value in opaque buffer inline, e.g.:
+
+```c++
+class swift::Array<swift::Int> {
+  ...
+  alignas(8) char buffer[8]; // Swift value is stored here.
+}
+```
+
+* Debug info: ...
+
+
+6) Generic opaque-layout / resilient / opaque-layout template type params Swift value type, e.g. SHA256`?`, is mapped to a C++ class that stores the value boxed up on the heap, e.g.:
+
+```c++
+class swift::Optional<CryptoKit::SHA256> {
+  ...
+  union {
+    alignas(8) char buffer[8]; 
+    void *resilientPtr;        // Swift value is stored on the heap pointed by this pointer.
+  };
+}
+```
+
+* Debug info: ...
+
+### Class Types
+
+Class type is mapped to a C++ class that has a pointer to the underlying Swift instance in the base class:
+
+```c++
+class BaseClass {
+private:
+  void *_opaquePointer; // Swift class instance pointer is stored here.
+}; 
+class Vehicle: public BaseClass {
+public:
+}
+```
+
+* Debug info: ...
+
+### Existential Types
+
+Error type is mapped to a specific C++ `swift::Error` class that stores the pointer to the error:
+
+```c++
+class Error {
+private:
+  void *_opaquePointer; // Swift error instance pointer is stored here.:
+};
+```
+
+* Debug info: ...
+
+
+Existential type. e.g. `any Hashable` maps to a C++ class that stores the opaque existential value (`swift::any<swift::Hashable>`):
+
+```c++
+class swift::OpaqueExistential {
+  // approximate layout.
+  alignas(8) char buffer[8*5]; // opaque existential is stored here (inline or boxed by Swift)
+};
+class swift::any<swift::Hashable>: public swift::OpaqueExistential {
+};
+```
+
+* Debug info: ...

docs/CppInteroperability/UserGuide-CallingSwiftFromC++.md

@@ -7,7 +7,7 @@ A Swift library author might want to expose their interface to C++, to allow a C
 **NOTE:** This document does not go over the following Swift language features yet:
 
 * Closures
-* Class types & inheritance
+* overriden methods/properties in classes
 * Existential types (any P)
 * Nested types
 * Operators
@@ -570,6 +570,102 @@ Barcode normalizeBarcode(Barcode barcode) {
 }
 ```
 
+## Using Swift Class Types
+
+Swift class types that are usable from C++ are available in their corresponding module namespace. They’re bridged over as a C++ class that stores a referenced counted pointer inside of it. Its initializers, methods and properties are exposed as members of the C++ class.
+
+### Reference counting in C++
+
+C++ class types that represent Swift classes perform automatic
+reference counting (ARC) operations when the C++ value that represents
+the reference to the Swift class is copied and destroyed.
+
+For example, the following Swift class:
+
+```swift
+// Swift module 'People'.
+class Person {
+  let name: String
+  init(name: String) {
+    self.name = name
+    print("\(name) is being initialized")
+  }
+  deinit {
+    print("\(name) is being deinitialized")
+  }
+}
+
+func createRandomPerson() -> Person {
+  return Person(name: getRandomName())
+}
+```
+
+Can be used from C++ with reference counting performed
+automatically:
+
+```c++
+#include "People-Swift.h"
+
+using namespace People;
+
+void doSomething(Person p) {
+  ...
+}
+
+void createAndUsePerson() {
+  Person p = createRandomPerson();
+
+  doSomething(p); // 'p' is copied. Person referenced by p is referenced twice.
+  // Destructor for copy of 'p' is called. Person referenced by p is referenced once.
+
+  // Destructor for 'p' gets called here. Person referenced by p is deallocated.
+}
+```
+
+The Swift `Person` class instance that C++ variable `p` referenced gets deallocated
+at the end of `createAndUsePerson` as the two C++ values that referenced it
+inside of `createAndUsePerson` were destroyed.
+
+### Class inheritance
+
+A Swift class that inherits from another class is bridged to C++ with that inheritance
+relationship preserved in the C++ class hierarchy generated for these Swift classes. For example, given the following two Swift classes:
+
+```swift
+// Swift module 'Transport'
+public class Vehicle {
+}
+public final class Bicycle: Vehicle {
+}
+```
+
+Get a corresponding C++ class hierachy in C++:
+
+```c++
+class Vehicle { ... };
+class Bicycle final : public Vehicle {};
+```
+
+This allows C++ code to implicitly cast derived class instances to base class reference values, like in the example below:
+
+```c++
+#include "Transport-Swift.h"
+
+using namespace Transport;
+
+void doSomethingWithVehicle(Transport::Vehicle vehicle) {
+  ...
+}
+
+void useBicycle() {
+  auto bike = Bicycle::init();
+  doSomethingWithVehicle(bike);
+}
+```
+
+Swift classes that are marked as `final` are also marked `final` in C++.
+Swift classes that are not marked as `final` should not be derived from in C++.
+
 ## Accessing Properties In C++
 
 Swift allows structures and classes to define stored and computed properties. Stored properties store constant and variable values as part of an instance, whereas computed properties calculate (rather than store) a value. The stored and the computed properties from Swift types are bridged over as getter `get...` and setter `set...` methods in C++. Setter methods are not marked as `const` and should only be invoked on non `const` instances of the bridged types.