Skip to content

Commit f3f8d8d

Browse files
Merge pull request #4371 from swiftwasm/main
[pull] swiftwasm from main
2 parents afc977b + e5bd9da commit f3f8d8d

File tree

506 files changed

+14559
-4781
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

506 files changed

+14559
-4781
lines changed

.gitignore

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -47,6 +47,9 @@ docs/_build
4747
.cache
4848
.clangd
4949

50+
# SwiftPM
51+
.build
52+
5053
#==============================================================================#
5154
# Ignore CMake temporary files
5255
#==============================================================================#
@@ -59,6 +62,7 @@ CMakeFiles
5962
#==============================================================================#
6063
compile_commands.json
6164

65+
#==============================================================================#
6266
# Ignore generated GYB files until we fix the workaround on Windows
6367
#==============================================================================#
6468
8

CHANGELOG.md

Lines changed: 20 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,23 @@ _**Note:** This is in reverse chronological order, so newer entries are added to
55

66
## Swift 5.7
77

8+
* [SE-0343][]:
9+
10+
Top-level scripts support asynchronous calls.
11+
12+
Using an `await` by calling an asynchronous function or accessing an isolated
13+
variable transitions the top-level to an asynchronous context. As an
14+
asynchronous context, top-level variables are `@MainActor`-isolated and the
15+
top-level is run on the `@MainActor`.
16+
17+
Note that the transition affects function overload resolution and starts an
18+
implicit run loop to drive the concurrency machinery.
19+
20+
Unmodified scripts are not affected by this change unless `-warn-concurrency` is
21+
passed to the compiler invocation. With `-warn-concurrency`, variables in the
22+
top-level are isolated to the main actor and the top-level context is isolated
23+
to the main actor, but is not an asynchronous context.
24+
825
* [SE-0336][]:
926

1027
It is now possible to declare `distributed actor` and `distributed func`s inside of them.
@@ -37,7 +54,7 @@ func talkTo(greeter: Greeter) async throws {
3754

3855
* The compiler now emits a warning when a non-final class conforms to a protocol that imposes a same-type requirement between `Self` and an associated type. This is because such a requirement makes the conformance unsound for subclasses.
3956

40-
For example, Swift 5.6 would allow the following code, which at runtime would construct an instanec of `C` and not `SubC` as expected:
57+
For example, Swift 5.6 would allow the following code, which at runtime would construct an instance of `C` and not `SubC` as expected:
4158

4259
```swift
4360
protocol P {
@@ -79,7 +96,7 @@ For example, Swift 5.6 would allow the following code, which at runtime would co
7996

8097
* [SE-0341][]:
8198

82-
Opaque types can now be used in the parameters of functions and subscripts, wher they provide a shorthand syntax for the introduction of a generic parameter. For example, the following:
99+
Opaque types can now be used in the parameters of functions and subscripts, when they provide a shorthand syntax for the introduction of a generic parameter. For example, the following:
83100

84101
```swift
85102
func horizontal(_ v1: some View, _ v2: some View) -> some View {
@@ -9065,6 +9082,7 @@ Swift 1.0
90659082
[SE-0335]: <https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md>
90669083
[SE-0341]: <https://github.com/apple/swift-evolution/blob/main/proposals/0341-opaque-parameters.md>
90679084
[SE-0336]: <https://github.com/apple/swift-evolution/blob/main/proposals/0336-distributed-actor-isolation.md>
9085+
[SE-0343]: <https://github.com/apple/swift-evolution/blob/main/proposals/0343-top-level-concurrency.md>
90689086

90699087
[SR-75]: <https://bugs.swift.org/browse/SR-75>
90709088
[SR-106]: <https://bugs.swift.org/browse/SR-106>

benchmark/single-source/SubstringTest.swift

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -63,21 +63,23 @@ public func run_SubstringFromLongStringGeneric(_ n: Int) {
6363
}
6464
}
6565

66-
@inline(never)
67-
public func run_StringFromLongWholeSubstring(_ n: Int) {
66+
private func getLongWideRealBuffer() -> String {
6867
var s0 = longWide
6968
s0 += "!" // ensure the string has a real buffer
70-
let s = Substring(s0)
69+
return s0
70+
}
71+
72+
@inline(never)
73+
public func run_StringFromLongWholeSubstring(_ n: Int) {
74+
let s = Substring(getLongWideRealBuffer())
7175
for _ in 1...n*500 {
7276
blackHole(String(s))
7377
}
7478
}
7579

7680
@inline(never)
7781
public func run_StringFromLongWholeSubstringGeneric(_ n: Int) {
78-
var s0 = longWide
79-
s0 += "!" // ensure the string has a real buffer
80-
let s = Substring(s0)
82+
let s = Substring(getLongWideRealBuffer())
8183
for _ in 1...n*500 {
8284
create(String.self, from: s)
8385
}

cmake/modules/Libdispatch.cmake

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -89,6 +89,8 @@ foreach(sdk ${DISPATCH_SDKS})
8989
${SWIFT_LIBDISPATCH_COMPILER_TRIPLE_CMAKE_ARGS}
9090
-DCMAKE_C_FLAGS=${CMAKE_C_FLAGS}
9191
-DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}
92+
-DCMAKE_EXE_LINKER_FLAGS=${CMAKE_EXE_LINKER_FLAGS}
93+
-DCMAKE_SHARED_LINKER_FLAGS=${CMAKE_SHARED_LINKER_FLAGS}
9294
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
9395
-DCMAKE_INSTALL_LIBDIR=lib
9496
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
Lines changed: 146 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
# C++ Interoperability Status
2+
3+
Swift has some experimental ability to interoperate with C++.
4+
This document provides an overview of the status of the Swift and C++ interoperability support.
5+
6+
## C++ to Swift Interoperability Status
7+
8+
Swift has the experimental ability to import a large subset of C++.
9+
This section of the document describes which C++ language and standard library features can be imported and used from Swift in an experimental manner.
10+
11+
### Example
12+
The following example demonstrates several interop features. It compiles and runs on main.
13+
14+
```C++
15+
// cxx-types.h (mapped to CxxTypes module in module.modulemap)
16+
#include <algorithm>
17+
#include <vector>
18+
19+
using V = std::vector<long>;
20+
```
21+
22+
```Swift
23+
// main.swift
24+
import CxxTypes
25+
import std.vector
26+
import std.algorithm
27+
28+
// We can extend C++ types in Swift.
29+
extension V : RandomAccessCollection {
30+
public var startIndex: Int { 0 }
31+
public var endIndex: Int { size() }
32+
}
33+
34+
// Create a vector with some data.
35+
var numbers = V(4)
36+
std.fill(numbers.beginMutating(), numbers.endMutating(), 41)
37+
38+
// Transform it using C++.
39+
std.transform(numbers.beginMutating(), numbers.endMutating(),
40+
numbers.beginMutating()) { (element: Int) in
41+
return element + 1
42+
}
43+
44+
// Loop over it in Swift.
45+
for (index, element) in numbers.enumerated() {
46+
print("v[\(index)] = \(element)")
47+
}
48+
49+
// We can also use anything in RandomAccessCollection, such as map and zip.
50+
let strings = numbers.map { "\($0)" }
51+
for (s, n) in zip(strings, numbers) {
52+
print("\(s) = \(n)")
53+
}
54+
```
55+
56+
### Importing C++
57+
58+
There are currently two experimental ways to import C++ into Swift:
59+
- **Clang modules**: can be imported into Swift. This requires a module map.
60+
- **Bridging header**: can be imported into Swift. Headers included in the bridging header will be imported.
61+
Please note that support for importing C++ 20 modules isn’t implemented.
62+
63+
Both CMake and the Swift package manager can be configured to invoke Swift with the correct arguments to import C++ headers.
64+
65+
**Note**: C++ code is imported using the Objective-C++ language mode on Apple platforms.
66+
67+
### Experimental C++ Language Support
68+
69+
This status table describes which of the following C++ language features can be used in Swift:
70+
71+
| **C++ Language Feature** | **Implemented Experimental Support For Using It In Swift** |
72+
|---------------------------------------------|---------------------------------------------------------------|
73+
| Top-level functions | Yes |
74+
| Enumerations | Yes. That includes `enum class` |
75+
| Struct / Class types | Yes - as value types, except for types without a copy constructor. Partial experimental support for importing a C++ struct/class as a reference type |
76+
| Typedefs / Type aliases | Yes |
77+
| Global Variables | Yes |
78+
| Namespaces | Yes |
79+
| Inline Namespaces | Yes, with some known issues (https://bugs.swift.org/browse/SR-15956) |
80+
| Exceptions | No |
81+
| Fields | Yes |
82+
| Member functions | Yes. Some value category overloads aren't imported |
83+
| Virtual Member Functions | No |
84+
| Operators | Yes, with some known issues |
85+
| Subscript Operators | Yes |
86+
| Constructors | Yes. That includes implicit constructors |
87+
| Destructor | Yes. C++ destructors are invoked automatically when the value is no longer used in Swift |
88+
| Copy constructor / copy assignment operator | Yes. Swift invokes the underlying copy constructor when copying a C++ value |
89+
| Move constructor / move assignment operator | No |
90+
| Base class member functions / operators | Yes, with some known issues |
91+
| Function templates | Yes |
92+
| Class templates | Yes |
93+
| Dependent types | Partially: imported as Any |
94+
| Availability Attributes | Yes |
95+
96+
97+
The following C++ code patterns or language features have specific mappings to Swift language features when imported in Swift:
98+
99+
100+
| **C++ Language Feature** | **Imported Into Swift** |
101+
|------------------------------------------------------|------------------------------------------------------------------------------------------|
102+
| `get`/`set` member functions | Imported as computed property (starting from Swift-5.7) |
103+
| `const`/non-`const` member function overload set | Both overloads are imported as a method, with non-`const` method being renamed to `mutating…` (starting from Swift-5.7). The renaming logic will change in a future version of Swift, and non-`const` methods won't be renamed |
104+
105+
106+
Unless stated otherwise (i.e., imported reference types) all Swift features work with imported types. For example: use in generic contexts, protocol conformance, extensions, etc.
107+
108+
109+
### C++ Standard Library Support
110+
111+
Parts of libc++ can be imported and used from Swift.
112+
113+
This status table describes which of the following C++ standard library features have some experimental support for using them in Swift. Please note that this is not a comprehensive list and other libc++ APIs that use the above supported C++ language features could be imported into Swift.
114+
115+
| **C++ Standard Library Feature** | **Can Be Used From Swift** |
116+
|------------------------------------|----------------------------------------------|
117+
| `std::string` | Yes |
118+
| `std::vector` | Yes |
119+
120+
## Known Issues
121+
122+
### Inline Namespaces
123+
- https://bugs.swift.org/browse/SR-15956: Swift's typechecker currently doesn't allow calling a function from an inline namespace when it's referenced through the parent namespace. Example of a test that fails: https://github.com/apple/swift/blob/main/test/Interop/Cxx/namespace/inline-namespace-function-call-broken.swift
124+
125+
126+
## Swift to C++ Interoperability Status
127+
128+
This section of the document describes which Swift language and standard library features can be imported and used from C++.
129+
130+
### Importing Swift
131+
132+
Swift has some experimental support for generating a header that can be imported by C++.
133+
134+
### Swift Language Support
135+
136+
This status table describes which of the following Swift language features have some experimental support for using them in C++.
137+
138+
**Functions**
139+
140+
| **Swift Language Feature** | **Implemented Experimental Support For Using It In C++** |
141+
|--------------------------------|----------------------------------------------------------|
142+
| Top-level `@_cdecl` functions | Yes |
143+
| Top-level Swift functions | Partially, only with C compatible types |
144+
| `inout` parameters | No |
145+
| Variadic parameters | No |
146+
| Multiple return values | No |

docs/README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -249,7 +249,7 @@ documentation, please create a thread on the Swift forums under the
249249
Describes the goals and design for Library Evolution.
250250
- [BuildManifesto.md](/docs/BuildManifesto.md):
251251
Provides an outline for modularizing the build system for the Swift toolchain.
252-
- [CppInteroperabilityManifesto.md](/docs/CppInteroperabilityManifesto.md):
252+
- [CppInteroperabilityManifesto.md](/docs/CppInteroperability/CppInteroperabilityManifesto.md):
253253
Describes the motivation and design for first-class Swift-C++ interoperability.
254254
- [DifferentiableProgramming.md](/docs/DifferentiableProgramming.md):
255255
Outlines a vision and design for first-class differentiable programming in Swift.

docs/ReferenceGuides/UnderscoredAttributes.md

Lines changed: 11 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -39,14 +39,19 @@ Most notably, default argument expressions are implicitly
3939
`@_alwaysEmitIntoClient`, which means that adding a default argument to a
4040
function which did not have one previously does not break ABI.
4141

42-
## `@_backDeploy(availabilitySpec ...)`
42+
## `@_backDeploy(before: ...)`
4343

4444
Causes the body of a function to be emitted into the module interface to be
45-
available for inlining in clients with deployment targets lower than the formal
46-
availability of the function. When inlined, the body of the function is
47-
transformed such that it calls the library's copy of the function if it is
48-
available at runtime. Otherwise, the copy of the original function body is
49-
executed.
45+
available for emission into clients with deployment targets lower than the
46+
ABI availability of the function. When the client's deployment target is
47+
before the function's ABI availability, the compiler replaces calls to that
48+
function with a call to a thunk that checks at runtime whether the original
49+
library function is available. If the the original is available then it is
50+
called. Otherwise, the fallback copy of the function that was emitted into the
51+
client is called instead.
52+
53+
For more details, see the [pitch thread](https://forums.swift.org/t/pitch-function-back-deployment/55769/)
54+
in the forums.
5055

5156
## `@_assemblyVision`
5257

include/swift/AST/ASTContext.h

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -988,11 +988,11 @@ class ASTContext final {
988988
/// one.
989989
void loadExtensions(NominalTypeDecl *nominal, unsigned previousGeneration);
990990

991-
/// Load the methods within the given class that produce
991+
/// Load the methods within the given type that produce
992992
/// Objective-C class or instance methods with the given selector.
993993
///
994-
/// \param classDecl The class in which we are searching for @objc methods.
995-
/// The search only considers this class and its extensions; not any
994+
/// \param tyDecl The type in which we are searching for @objc methods.
995+
/// The search only considers this type and its extensions; not any
996996
/// superclasses.
997997
///
998998
/// \param selector The selector to search for.
@@ -1010,7 +1010,11 @@ class ASTContext final {
10101010
///
10111011
/// \param swiftOnly If true, only loads methods from imported Swift modules,
10121012
/// skipping the Clang importer.
1013-
void loadObjCMethods(ClassDecl *classDecl, ObjCSelector selector,
1013+
///
1014+
/// \note Passing a protocol is supported, but currently a no-op, because
1015+
/// Objective-C protocols cannot be extended in ways that make the ObjC method
1016+
/// lookup table relevant.
1017+
void loadObjCMethods(NominalTypeDecl *tyDecl, ObjCSelector selector,
10141018
bool isInstanceMethod, unsigned previousGeneration,
10151019
llvm::TinyPtrVector<AbstractFunctionDecl *> &methods,
10161020
bool swiftOnly = false);

include/swift/AST/ASTMangler.h

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -186,6 +186,8 @@ class ASTMangler : public Mangler {
186186
Type GlobalActorBound,
187187
ModuleDecl *Module);
188188

189+
std::string mangleDistributedThunk(const FuncDecl *thunk);
190+
189191
/// Mangle a completion handler block implementation function, used for importing ObjC
190192
/// APIs as async.
191193
///

0 commit comments

Comments
 (0)