You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+182Lines changed: 182 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,178 @@ _**Note:** This is in reverse chronological order, so newer entries are added to
5
5
6
6
## Swift 5.7
7
7
8
+
*[SE-0338][]:
9
+
10
+
Non-isolated async functions now always execute on the global concurrent pool,
11
+
so calling a non-isolated async function from actor-isolated code will leave
12
+
the actor. For example:
13
+
14
+
```swift
15
+
classC { }
16
+
17
+
funcf(_: C) async { /* always executes on the global concurrent pool */ }
18
+
19
+
actorA {
20
+
funcg(c: C) async {
21
+
/* always executes on the actor */
22
+
print("on the actor")
23
+
24
+
awaitf(c)
25
+
}
26
+
}
27
+
```
28
+
29
+
Prior to this change, the call from `f` to `g` might have started execution of
30
+
`g` on the actor, which could lead to actors being busy longer than strictly
31
+
necessary. Now, the non-isolated async function will always hop to the global
32
+
cooperative pool, not run on the actor. This can result in a behavior change
33
+
for programs that assumed that a non-isolated async function called from a
34
+
`@MainActor` context will be executed on the main actor, although such
35
+
programs were already technically incorrect.
36
+
37
+
Additionally, when leaving an actor to execution on the global cooperative
38
+
pool, `Sendable` checking will be performed, so the compiler will emit a
39
+
diagnostic in the call to `f` if `c` is not of `Sendable` type.
40
+
41
+
*[SE-0350][]:
42
+
43
+
The standard library has a new `Regex<Output>` type.
44
+
45
+
This type represents an _extended regular expression_, allowing more fluent
46
+
string processing operations. A `Regex` may be created by
47
+
[initialization from a string][SE-0355]:
48
+
```
49
+
let pattern = "a[bc]+" // matches "a" followed by one or more instances
50
+
// of either "b" or "c"
51
+
let regex = try! Regex(pattern)
52
+
```
53
+
Or via a [regex literal][SE-0354]:
54
+
```
55
+
let regex = #/a[bc]+/#
56
+
```
57
+
In Swift 6, `/` will also be supported as a delimiter for `Regex` literals.
58
+
You can enable this mode in Swift 5.7 with the `-enable-bare-slash-regex`
59
+
flag. Doing so will cause some existing expressions that use `/` as an
60
+
operator to no longer compile; you can add parentheses or line breaks as a
61
+
workaround.
62
+
63
+
There are [new string-processing algorithms][SE-0357] that support
64
+
`String`, `Regex` and arbitrary `Collection` types.
65
+
66
+
*[SE-0329][]:
67
+
New types representing time and clocks were introduced. This includes a protocol `Clock` defining clocks which allow for defining a concept of now and a way to wake up after a given instant. Additionally a new protocol `InstantProtocol` for defining instants in time was added. Furthermore a new protocol `DurationProtocol` was added to define an elapsed duration between two given `InstantProtocol` types. Most commonly the `Clock` types for general use are the `SuspendingClock` and `ContinuousClock` which represent the most fundamental clocks for the system. The `SuspendingClock` type does not progress while the machine is suspended whereas the `ContinuousClock` progresses no matter the state of the machine.
`Clock` also has methods to measure the elapsed duration of the execution of work. In the case of the `SuspendingClock` and `ContinuousClock` this measures with high resolution and is suitable for benchmarks.
77
+
78
+
```swift
79
+
let clock =ContinuousClock()
80
+
let elapsed = clock.measure {
81
+
someLongRunningWork()
82
+
}
83
+
```
84
+
85
+
*[SE-0309][]:
86
+
87
+
Protocols with associated types and `Self` requirements can now be used as the
88
+
types of values with the `any` keyword.
89
+
90
+
Protocol methods that return associated types can be called on an `any` type;
91
+
the result is type-erased to the associated type's upper bound, which is another
92
+
`any` type having the same constraints as the associated type. For example:
93
+
94
+
```swift
95
+
protocolSurface {...}
96
+
97
+
protocolSolid {
98
+
associatedtypeSurfaceType: Surface
99
+
funcboundary() -> SurfaceType
100
+
}
101
+
102
+
let solid: any Solid =...
103
+
104
+
// Type of 'boundary' is 'any Surface'
105
+
let boundary = solid.boundary()
106
+
```
107
+
108
+
Protocol methods that take an associated type or `Self` cannot be used with `any`,
109
+
however in conjunction with [SE-0352][], you can pass the `any` type to a function
110
+
taking a generic parameter constrained to the protocol. Within the generic context,
111
+
type relationships are explicit and all protocol methods can be used.
112
+
113
+
*[SE-0346][]:
114
+
115
+
Protocols can now declare a list of one or more _primary associated types_, which enable writing same-type requirements on those associated types using angle bracket syntax:
116
+
117
+
```swift
118
+
protocolGraph<Vertex, Edge> {
119
+
associatedtypeVertex
120
+
associatedtypeEdge
121
+
}
122
+
```
123
+
124
+
You can now write a protocol name followed by type arguments in angle brackets, like
125
+
`Graph<Int, String>`, anywhere that a protocol conformance requirement may appear:
126
+
127
+
```swift
128
+
funcshortestPath<V, E>(_: some Graph<V, E>, from: V, to: V) -> [E]
129
+
130
+
extensionGraph<Int, String> {...}
131
+
132
+
funcbuild() ->some Graph<Int, String> {}
133
+
```
134
+
135
+
A protocol name followed by angle brackets is shorthand for a conformance requirement,
136
+
together with a same-type requirement for the protocol's primary associated types.
137
+
The first two examples above are equivalent to the following:
138
+
139
+
```swift
140
+
funcshortestPath<V, E, G>(_: G, from: V, to: V) -> [E]
The `build()` function returning `some Graph<Int, String>` can't be written using a
147
+
`where` clause; this is an example of a constrained opaque result type, which is new expressivity in Swift 5.7.
148
+
149
+
*[SE-0353][]:
150
+
151
+
Protocols with primary associated types can now be used in existential types,
152
+
enabling same-type constraints on those associated types.
153
+
154
+
```
155
+
let strings: any Collection<String> = [ "Hello" ]
156
+
```
157
+
158
+
Note that language features requiring runtime support like dynamic casts
159
+
(`is`, `as?`, `as!`), as well as generic usages of parameterized existentials
160
+
in generic types (e.g. `Array<any Collection<Int>>`) involve additional
161
+
availability checks to use. Back-deploying usages in generic position can be
162
+
worked around with a generic type-erasing wrapper struct, which is now much
163
+
simpler to implement:
164
+
165
+
```swift
166
+
structAnyCollection<T> {
167
+
var wrapped: anyCollection<T>
168
+
}
169
+
170
+
let arrayOfCollections: [AnyCollection<T>] = [ /**/ ]
171
+
```
172
+
173
+
*[SE-0358][]:
174
+
175
+
Various protocols in the standard library now declare primary associated types, for
176
+
example `Sequence` and `Collection` declare a single primary associated type `Element`.
177
+
For example, this allows writing down the types `some Collection<Int>` and
178
+
`any Collection<Int>`.
179
+
8
180
* References to `optional` methods on a protocol metatype, as well as references to dynamically looked up methods on the `AnyObject` metatype are now supported. These references always have the type of a function that accepts a single argument and returns an optional value of function type:
Copy file name to clipboardExpand all lines: docs/DevelopmentTips.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,19 +92,21 @@ This is very convenient because you get the benefits of the ninja build system a
92
92
93
93
To setup this environment a few steps are necessary:
94
94
* Create a new workspace.
95
-
* Create Xcode projects for LLVM and Swift with `utils/build-script --skip-build --xcode --skip-early-swift-driver`. Beside configuring, this needs to build a few LLVM files which are need to configure the swift project.
95
+
* Create Xcode projects for LLVM and Swift with `utils/build-script --skip-build --xcode --skip-early-swift-driver`. Beside configuring, this needs to build a few LLVM files which are needed to configure the swift project.
96
96
* Add the generated LLVM and Swift projects to your workspace. They can be found in the build directories `build/Xcode-DebugAssert/llvm-macosx-x86_64/LLVM.xcodeproj` and `build/Xcode-DebugAssert/swift-macosx-x86_64/Swift.xcodeproj`.
97
97
* Add the `swift/SwiftCompilerSources` package to the workspace.
98
98
* Create a new empty project `build-targets` (or however you want to name it) in the workspace, using the "External Build System" template.
99
99
* For each compiler tool you want to build (`swift-frontend`, `sil-opt`, etc.), add an "External Build System" target to the `build-targets` project.
100
-
* In the "Info" section of the target configuration, set
101
-
* the _Build Tool_ to the full path of the `ninja` command
102
-
* the _Argument_ to the tool name (e.g. `swift-frontend`)
103
-
* the _Directory_ to the ninja swift build directory, e.g. `/absolute/path/to/build/Ninja-DebugAssert/swift-macosx-x86_64`. For debugging to work, this has to be a debug build of course.
100
+
* In the "Info" section of the target configuration, set:
101
+
* the _Build Tool_ to the full path of the `ninja` command
102
+
* the _Argument_ to the tool name (e.g. `swift-frontend`)
103
+
* the _Directory_ to the ninja swift build directory, e.g. `/absolute/path/to/build/Ninja-DebugAssert/swift-macosx-x86_64`. For debugging to work, this has to be a debug build of course.
104
104
* For each target, create a new scheme:
105
-
* In the _Build_ section add the corresponding build target what you created before.
105
+
* In the _Build_ section add the corresponding build target that you created before.
106
106
* In the _Run/Info_ section select the built _Executable_ in the build directory (e.g. `/absolute/path/to/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift-frontend`).
107
107
* In the _Run/Arguments_ section you can set the command line arguments with which you want to run the compiler tool.
108
108
* In the _Run/Options_ section you can set the working directory for debugging.
109
109
110
-
Now you are all set. You can build and debug like with a native Xcode project.
110
+
Now you are all set. You can build and debug like with a native Xcode project.
111
+
112
+
If the project structure changes, e.g. new source files are added or deleted, you just have to re-create the LLVM and Swift projects with `utils/build-script --skip-build --xcode --skip-early-swift-driver`.
Copy file name to clipboardExpand all lines: docs/HowToGuides/GettingStarted.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -282,6 +282,8 @@ The additional flexibility comes with two issues: (1) consuming much more disk
282
282
space and (2) you need to maintain the two builds in sync, which needs extra
283
283
care when moving across branches.
284
284
285
+
It is even possible to integrate the Ninja build into Xcode. For details on how to set this up see [Using Ninja with Xcode in DevelopmentTips.md](/docs/DevelopmentTips.md#using-ninja-with-xcode).
286
+
285
287
### Troubleshooting build issues
286
288
287
289
- Double-check that all projects are checked out at the right branches.
0 commit comments