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
Re-generate diagnostics index and cleanup old notes
This is mostly just cleanup:
1. Removes `diagnostic-descriptions.md` since it isn't used any more
2. Adds the group name to all the old notes files
3. Removes trailing whitespace
4. Adds "See Also" sections for notes that have links
Copy file name to clipboardExpand all lines: userdocs/diagnostics/actor-isolated-call.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,6 @@
1
-
# Calling an actor-isolated method from a synchronous nonisolated context
1
+
# Calling an actor-isolated method from a synchronous nonisolated context (ActorIsolatedCall)
2
+
3
+
## Overview
2
4
3
5
Accessing actor-isolated state from outside the actor can cause data races in your program. Resolve this error by calling actor-isolated functions on the actor.
Copy file name to clipboardExpand all lines: userdocs/diagnostics/conformance-isolation.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,6 @@
1
-
# Protocol conformances crossing into actor-isolated code
1
+
# Protocol conformances crossing into actor-isolated code (ConformanceIsolation)
2
+
3
+
## Overview
2
4
3
5
Protocol conformances crossing into actor-isolated code can cause data races in your program. Resolve this error by ensuring access to isolated state is always done within the actor.
If a type is marked with the `@dynamicCallable` attribute, it must provide a valid implementation of `dynamicallyCall(withArguments:)`, `dynamicallyCall(withKeywordArguments:)`, or both. If it fails to do so, an error will be reported at compile-time. Note that an implementation of `dynamicallyCall(withKeywordArguments:)` is required to support calls with keyword arguments.
3
6
4
7
To be considered valid, an implementation of `dynamicallyCall(withArguments:)` must:
@@ -10,4 +13,8 @@ To be considered valid, an implementation of `dynamicallyCall(withKeywordArgumen
10
13
- Be an instance method. `static` or `class` implementations are not allowed.
11
14
- Have an argument type which conforms to the `ExpressibleByDictionaryLiteral` protocol. This can be `Dictionary`, `KeyValuePairs` (which may be used to support duplicated keyword arguments), or some other conforming type.
12
15
- The `Key` associated type of the argument type must conform to the `ExpressibleByStringLiteral` protocol. This type is used to represent the dynamic argument keywords.
13
-
- The `Value` associated type of the argument type and the return type of `dynamicallyCall(withKeywordArguments:)` may be any valid types.
16
+
- The `Value` associated type of the argument type and the return type of `dynamicallyCall(withKeywordArguments:)` may be any valid types.
# Language mode and tools version (ErrorInFutureSwiftVersion)
2
+
3
+
## Overview
2
4
3
5
Swift language mode and Swift compiler tools version are distinct concepts. One compiler version can support multiple language modes.
4
6
@@ -7,6 +9,6 @@ There are two related kinds of "Swift version" that are distinct:
7
9
* Swift tools version: the version number of the compiler itself. For example, the Swift 5.6 compiler was introduced in March 2022.
8
10
* Swift language mode version: the language mode version with which we are providing source compatibility. For example, the Swift 5 language mode is the most current language mode version supported by Swift tools version 5.10.
9
11
10
-
The Swift tools support multiple Swift language modes. All Swift tools versions between 5.0 and 5.10 support three Swift language modes: 4, 4.2, and 5. The Swift 6.0 compiler supports four Swift language modes: 4, 4.2, 5, and 6. Swift language modes are opt-in; when you use a tools version that supports a new language mode, your code will not build with the new language mode until you set that language mode in your build settings with `-swift-version X`.
12
+
The Swift tools support multiple Swift language modes. All Swift tools versions between 5.0 and 5.10 support three Swift language modes: 4, 4.2, and 5. The Swift 6.0 compiler supports four Swift language modes: 4, 4.2, 5, and 6. Swift language modes are opt-in; when you use a tools version that supports a new language mode, your code will not build with the new language mode until you set that language mode in your build settings with `-language-mode X`.
11
13
12
14
A warning suffixed with `this is an error in the Swift 6 language mode` means that once you migrate to that language mode in your code, the warning will be promoted to an error. These warnings primarily come from enabling upcoming features that are enabled by default in that language mode version, but errors may also be staged in as warnings until the next language mode to maintain source compatibility when fixing compiler bugs.
Copy file name to clipboardExpand all lines: userdocs/diagnostics/exclusivity-violation.md
+10-2Lines changed: 10 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,6 @@
1
-
# Overlapping accesses, but operation requires exclusive access
1
+
# Overlapping accesses, but operation requires exclusive access (ExclusivityViolation)
2
+
3
+
## Overview
2
4
3
5
Swift requires exclusive access to a variable in order to modify that variable. An error is reported if a program attempts to access a variable while it is already in the process of being accessed via another name. These issues can often be resolved by making a local copy of a variable before modifying it.
4
6
@@ -58,4 +60,10 @@ var toAppend = numbers
58
60
numbers.append(removingFrom: &toAppend)
59
61
```
60
62
61
-
Exclusivity checks play an important role in enforcing memory safety and enabling compiler optimizations. To learn more, see [Swift 5 Exclusivity Enforcement](https://www.swift.org/blog/swift-5-exclusivity/) on the Swift.org blog.
63
+
Exclusivity checks play an important role in enforcing memory safety and enabling compiler optimizations. See the Swift.org [blog][exclusivity-enforcement] to learn more.
Copy file name to clipboardExpand all lines: userdocs/diagnostics/existential-member-access-limitations.md
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Using Protocol Members with References to `Self` or `Self`-rooted Associated Types
1
+
# Using protocol members with references to `Self` or `Self`-rooted associated types (ExistentialMemberAccess)
2
2
3
3
Protocol requirements and protocol extension members may be accessed via a conformance constraint on a generic parameter, an opaque result type, or via the protocol type itself:
Most use cases involving usage of protocol members that fall under the above restriction can instead be supported by constrained generics, opaque result types, or manual type-erasing wrappers. To learn more, see the sections on [protocols](https://docs.swift.org/swift-book/LanguageGuide/Protocols.html), [generics](https://docs.swift.org/swift-book/LanguageGuide/Generics.html), and [opaque types](https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes.html) in the Language Guide. For a better understanding of existential types in particular, and an in-depth exploration of the relationships among these built-in abstraction models, we recommend reading the [design document for improving the UI of the generics model](https://forums.swift.org/t/improving-the-ui-of-generics/22814).
54
+
Most use cases involving usage of protocol members that fall under the above restriction can instead be supported by constrained generics, opaque result types, or manual type-erasing wrappers. To learn more, see the sections on [protocols], [generics], and [opaque types][opaque-types] in the Language Guide. For a better understanding of existential types in particular, and an in-depth exploration of the relationships among these built-in abstraction models, we recommend reading [design document for improving the UI of the generics model][improving-generics-ui].
55
+
56
+
## See Also
57
+
58
+
-[Generics][generics]
59
+
-[Improving the UI of generics][improving-generics-ui]
Copy file name to clipboardExpand all lines: userdocs/diagnostics/implementation-only-deprecated.md
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,11 +2,12 @@
2
2
3
3
Warnings that identify `import` declarations with the `@_implementationOnly` attribute.
4
4
5
+
5
6
## Overview
6
7
7
8
When applied to `import` declarations, the compiler-internal attribute `@_implementationOnly` attempts prevents declarations from the imported module from being exposed in the ABI or public interface of the dependent module. This attribute became deprecated when support for access levels on `import` declarations was introduced with [SE-0409].
8
9
9
-
One reason `@_implementationOnly import` is deprecated is that it is unsafe when used in modules that are built _without_[library evolution] enabled. For example, suppose the following code were part of a library named `Foo`:
10
+
One reason `@_implementationOnly import` is deprecated is that it is unsafe when used in modules that are built _without_[library evolution][library-evolution] enabled. For example, suppose the following code were part of a library named `Foo`:
10
11
11
12
```swift
12
13
// Library `Foo`
@@ -19,5 +20,10 @@ public struct Bar {
19
20
20
21
If `Foo` is not compiled with library evolution, then the memory layout of values of `Bar` must be known at compile time in clients of `Foo`. However, the `@_implementationOnly import` of `ImplementationDetail` prevents clients from being able to look up `Baz` which is a type that contributes to the layout of `Foo`. As a result, the layout of `Foo` will be miscalculated resulting in undefined behavior.
0 commit comments