averello/swift-mirror
1
0
Fork 0
mirror of https://github.com/apple/swift.git synced 2025-12-14 20:36:38 +01:00
Code Issues Packages Projects Releases Wiki Activity

[docs] Update links to repositories moved to https://github.com/swiftlang/

Browse Source
This commit is contained in:
LamTrinh.Dev
2024-07-23 02:22:43 +07:00
committed by GitHub
parent 71c27a9d17
commit b6239b8cee
39 changed files with 184 additions and 184 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
docs/ABIStabilityManifesto.md
View File

@@ -44,7 +44,7 @@ As noted earlier, ABI stability is necessary, though not sufficient, for binary
### Library Evolution
Expressive and performance-focused languages which have binary interfaces tend to exhibit the [fragile binary interface problem](https://en.wikipedia.org/wiki/Fragile_binary_interface_problem), which makes it difficult for any library or component to change over time without requiring every user to recompile with new versions of that library. A major push in Swift currently is the plan for [Library Evolution](https://github.com/apple/swift/blob/main/docs/LibraryEvolution.rst), which aims to grant flexibility for library authors to maintain backwards and forwards binary compatibility. Many implementation concerns therein could have an impact on ABI.
Expressive and performance-focused languages which have binary interfaces tend to exhibit the [fragile binary interface problem](https://en.wikipedia.org/wiki/Fragile_binary_interface_problem), which makes it difficult for any library or component to change over time without requiring every user to recompile with new versions of that library. A major push in Swift currently is the plan for [Library Evolution](https://github.com/swiftlang/swift/blob/main/docs/LibraryEvolution.rst), which aims to grant flexibility for library authors to maintain backwards and forwards binary compatibility. Many implementation concerns therein could have an impact on ABI.
One of the goals of rolling out ABI stability is to remain flexible enough to accommodate library evolution changes without limiting the design space. Library evolution concerns will be addressed in each individual section, though a common refrain will be that the details are still undecided.
@@ -106,17 +106,17 @@ Opaque layout occurs whenever the layout is not known until runtime. This can co
The size and alignment of an object of opaque layout, as well as whether it is trivial or bitwise movable, is determined by querying its value witness table, which is described further in the [value witness table section](#value-witness-table). The offsets for data members are determined by querying the type's metadata, which is described further in the [value metadata section](#value-metadata). Objects of opaque layout must typically be passed indirectly, described further in the [function signature lowering section](#function-signature-lowering). The Swift runtime interacts with objects of opaque layout through pointers, and thus they must be addressable, described further in the [abstraction levels section](#abstraction-levels).
In practice, layout might be partially-known at compilation time. An example is a generic struct over type `T` that stores an integer as well as an object of type `T`. In this case, the layout of the integer itself is known and its location within the generic struct might be as well, depending on the specifics of the layout algorithm. However, the generic stored property has opaque layout, and thus the struct overall has an unknown size and alignment. We are investigating how to most efficiently lay out partially-opaque aggregates [[#46307](https://github.com/apple/swift/issues/46307)]. This will likely entail placing the opaque members at the end in order to guarantee known offsets of non-opaque data members.
In practice, layout might be partially-known at compilation time. An example is a generic struct over type `T` that stores an integer as well as an object of type `T`. In this case, the layout of the integer itself is known and its location within the generic struct might be as well, depending on the specifics of the layout algorithm. However, the generic stored property has opaque layout, and thus the struct overall has an unknown size and alignment. We are investigating how to most efficiently lay out partially-opaque aggregates [[#46307](https://github.com/swiftlang/swift/issues/46307)]. This will likely entail placing the opaque members at the end in order to guarantee known offsets of non-opaque data members.
#### <a name="layout-library-evolution"></a>Library Evolution
Library evolution introduces *resilient* layouts of public types by default and provides new annotations that freeze the layout for performance. A resilient layout avoids many of the pitfalls of the fragile binary problem by making the layout opaque. Resilient types have far more freedom to change and evolve without breaking binary compatibility: public data members can be rearranged, added, and even removed (by providing a computed getter/setter instead). The new annotations provide the ability to relinquish these freedoms by making stricter guarantees about their layout in order to be more efficiently compiled and accessed.
In order to allow for cross-module optimizations for modules that are distributed together, there is the concept of a *resilience domain*. A resilience domain is a grouping of modules which are version-locked with each other and thus do not have binary compatibility across multiple version requirements with each other. See [Resilience Domains](https://github.com/apple/swift/blob/main/docs/LibraryEvolution.rst#resilience-domains) for more details.
In order to allow for cross-module optimizations for modules that are distributed together, there is the concept of a *resilience domain*. A resilience domain is a grouping of modules which are version-locked with each other and thus do not have binary compatibility across multiple version requirements with each other. See [Resilience Domains](https://github.com/swiftlang/swift/blob/main/docs/LibraryEvolution.rst#resilience-domains) for more details.
Resilient types are required to have opaque layout when exposed outside their resilience domain. Inside a resilience domain, this requirement is lifted and their layout may be statically known or opaque as determined by their type (see [previous section](#opaque-layout)).
Annotations may be applied to a library's types in future versions of that library, in which case the annotations are versioned, yet the library remains binary compatible. How this will impact the ABI is still under investigation [[#46496](https://github.com/apple/swift/issues/46496)].
Annotations may be applied to a library's types in future versions of that library, in which case the annotations are versioned, yet the library remains binary compatible. How this will impact the ABI is still under investigation [[#46496](https://github.com/swiftlang/swift/issues/46496)].
#### <a name="abstraction-levels"></a>Abstraction Levels
@@ -132,9 +132,9 @@ What follows is a breakdown of the different kinds of types in Swift and what ne
#### Structs
The layout algorithm for structs should result in an efficient use of space, possibly by laying out fields in a different order than declared [[#46308](https://github.com/apple/swift/issues/46308)]. We may want a fully declaration-order-agnostic algorithm to allow data members to be reordered in source without breaking binary compatibility [[#46309](https://github.com/apple/swift/issues/46309)]. We also need to consider whether, by default, we want to ensure struct data members are addressable (i.e. byte-aligned) or if we'd rather do bit-packing to save space [[#46310](https://github.com/apple/swift/issues/46310)].
The layout algorithm for structs should result in an efficient use of space, possibly by laying out fields in a different order than declared [[#46308](https://github.com/swiftlang/swift/issues/46308)]. We may want a fully declaration-order-agnostic algorithm to allow data members to be reordered in source without breaking binary compatibility [[#46309](https://github.com/swiftlang/swift/issues/46309)]. We also need to consider whether, by default, we want to ensure struct data members are addressable (i.e. byte-aligned) or if we'd rather do bit-packing to save space [[#46310](https://github.com/swiftlang/swift/issues/46310)].
Zero sized structs do not take up any space as data members and struct members may be laid out in the padding of sub-structs. We may want to explore whether there are implementation benefits to capping alignment at some number, e.g. 16 on many platforms [[#46497](https://github.com/apple/swift/issues/46497)].
Zero sized structs do not take up any space as data members and struct members may be laid out in the padding of sub-structs. We may want to explore whether there are implementation benefits to capping alignment at some number, e.g. 16 on many platforms [[#46497](https://github.com/swiftlang/swift/issues/46497)].
#### <a name="tuples"></a>Tuples
@@ -142,7 +142,7 @@ Tuples are similar to anonymous structs, but they differ in that they exhibit st
This may be an argument for a simple, declaration-order, non bit-packed layout algorithm for tuples. Tuples are often used for small local values and rarely persisted across ABI boundaries in a way that aggressive packing is performance-critical. This would also be more consistent with how fixed-size C arrays are presented in Swift, which are imported as tuples.
We should investigate whether to aggressively bit-pack tuple elements similarly to structs, paying the reabstraction costs, or if the benefits are not worth the costs [[#46311](https://github.com/apple/swift/issues/46311)].
We should investigate whether to aggressively bit-pack tuple elements similarly to structs, paying the reabstraction costs, or if the benefits are not worth the costs [[#46311](https://github.com/swiftlang/swift/issues/46311)].
Tuples should be binary compatible between labeled and unlabeled tuples of the same type and structure.
@@ -161,7 +161,7 @@ Degenerate enums take zero space. Trivial enums are just their discriminator.
Single payload enums try to fit their discriminator in the payload's extra inhabitants for the non-payload cases, otherwise they will store the discriminator after the payload. When the discriminator is stored after the payload, the bits are not set for the payload case. The payload is guaranteed to be layout compatible with the enum as the payload case does not use any extra inhabitants. Storing the discriminator after the payload may also result in more efficient layout of aggregates containing the enum, due to alignment.
The layout algorithm for multi-payload enums is more complicated and still needs to be developed [[#46312](https://github.com/apple/swift/issues/46312)]. The algorithm should try to rearrange payloads so as to coalesce cases and save space. This rearrangement can also improve performance and code size. For example, if ARC-ed payload components reside in the same location, operations like copy can be done directly on the values without extensive switching.
The layout algorithm for multi-payload enums is more complicated and still needs to be developed [[#46312](https://github.com/swiftlang/swift/issues/46312)]. The algorithm should try to rearrange payloads so as to coalesce cases and save space. This rearrangement can also improve performance and code size. For example, if ARC-ed payload components reside in the same location, operations like copy can be done directly on the values without extensive switching.
Enum raw values are not ABI, as they are implemented as code present in the computed property getter and setter. `@objc` enums are C-compatible, which means they must be trivial.
@@ -177,7 +177,7 @@ The layout of class instances is mostly opaque. This is to avoid the vexing prob
The run-time type of a non-final class instance or a class existential is not known statically. To facilitate dynamic casts, the object must store a pointer to its type, called the *isa* pointer. The *isa* pointer is always stored at offset 0 within the object. How that type is represented and what information it provides is part of the class's metadata and is covered in the [class metadata section](#class-metadata). Similarly, the function for a non-final method call is also not known statically and is dispatched based on the run-time type. Method dispatch is covered in the [method dispatch section](#method-dispatch).
Class instances will, as part of ABI-stability, guarantee a word-sized field of opaque data following the isa field that may be used for reference counting by the runtime [[#46932](https://github.com/apple/swift/issues/46932)]. But, the format and conventions of this opaque data will not be ABI at first in order to have more flexibility for language or implementation changes. Instead, runtime functions provide the means to interact with reference counts. This opaque data and its conventions may be locked down for more efficient access in the future, which will be an ABI-additive change.
Class instances will, as part of ABI-stability, guarantee a word-sized field of opaque data following the isa field that may be used for reference counting by the runtime [[#46932](https://github.com/swiftlang/swift/issues/46932)]. But, the format and conventions of this opaque data will not be ABI at first in order to have more flexibility for language or implementation changes. Instead, runtime functions provide the means to interact with reference counts. This opaque data and its conventions may be locked down for more efficient access in the future, which will be an ABI-additive change.
##### References
@@ -187,7 +187,7 @@ References to Objective-C-compatible class instances (i.e. those that inherit fr
References to native, non-Objective-C-compatible Swift class instances do not have this constraint. The alignment of native Swift class instances is part of ABI, providing spare bits in the lower bits of references. Platforms may also provide spare bits (typically upper bits) and extra inhabitants (typically lower addresses) for references due to limited address spaces.
We may want to explore using spare bits in references to store local reference counts in order to perform some ARC operations more efficiently [[#46313](https://github.com/apple/swift/issues/46313)]. These would need to be flushed to the object whenever a reference may escape or the local reference count reaches zero. If these local reference counts can cross ABI boundaries, then such a change will have to be implemented in an ABI-additive way with deployment target checking.
We may want to explore using spare bits in references to store local reference counts in order to perform some ARC operations more efficiently [[#46313](https://github.com/swiftlang/swift/issues/46313)]. These would need to be flushed to the object whenever a reference may escape or the local reference count reaches zero. If these local reference counts can cross ABI boundaries, then such a change will have to be implemented in an ABI-additive way with deployment target checking.
#### <a name="existential-containers"></a>Existential Containers
@@ -205,15 +205,15 @@ A type's conformance to a protocol consists of functions (whether methods or get
Class-constrained existentials omit the metadata pointer (as the object itself contains a pointer to its type), as well as any excess inline buffer space. `Any`, which is an existential value without any conformances, has no witness table pointer.
We are re-evaluating the inline buffer size for existential containers prior to ABI stability [[#45928](https://github.com/apple/swift/issues/45928)]. We are also considering making the out-of-line allocation be copy-on-write (COW) [[#46913](https://github.com/apple/swift/issues/46913)]. We should also explore "exploding" existential parameters, i.e. converting an existential parameter into a protocol-constrained generic parameter [[#46914](https://github.com/apple/swift/issues/46914)].
We are re-evaluating the inline buffer size for existential containers prior to ABI stability [[#45928](https://github.com/swiftlang/swift/issues/45928)]. We are also considering making the out-of-line allocation be copy-on-write (COW) [[#46913](https://github.com/swiftlang/swift/issues/46913)]. We should also explore "exploding" existential parameters, i.e. converting an existential parameter into a protocol-constrained generic parameter [[#46914](https://github.com/swiftlang/swift/issues/46914)].
### Declaring Stability
ABI stability means nailing down type layout and making decisions about how to handle the concerns of Library Evolution. The end result will be a technical specification of the layout algorithms that future compilers must adhere to in order to ensure binary compatibility [[#46315](https://github.com/apple/swift/issues/46315)].
ABI stability means nailing down type layout and making decisions about how to handle the concerns of Library Evolution. The end result will be a technical specification of the layout algorithms that future compilers must adhere to in order to ensure binary compatibility [[#46315](https://github.com/swiftlang/swift/issues/46315)].
For all of the areas discussed above, more aggressive layout improvements may be invented in the post-ABI stability future. For example, we may want to explore rearranging and packing nested type data members with outer type data members. Such improvements would have to be done in an ABI-additive fashion through deployment target and/or min-version checking. This may mean that the module file will need to track per-type ABI versioning information.
A potentially out of date description of Swift's current type layout can be found in the [Type Layout docs](https://github.com/apple/swift/blob/main/docs/ABI/TypeLayout.rst).
A potentially out of date description of Swift's current type layout can be found in the [Type Layout docs](https://github.com/swiftlang/swift/blob/main/docs/ABI/TypeLayout.rst).
## <a name="metadata"></a>Type Metadata
@@ -222,15 +222,15 @@ While data layout specifies the layout of objects of a given type, *type metadat
Swift keeps metadata records for every *concrete type*. Concrete types include all non-generic types as well as generic types with concrete type parameters. These records are created by the compiler as well as lazily created at run time (e.g. for generic type instantiations). This metadata stores information about its type, discussed in each section below.
A potential approach to stability mechanism is to provide metadata read/write functions alongside the runtime to interact with metadata, giving some freedom to the underlying structures to grow and change. This effectively makes large portions of metadata opaque. But, certain fields require access to be as efficient as possible (e.g. dynamic casts, calling into witness tables) and the performance hit from going through an intermediary function would be unacceptable. Thus, we will probably freeze the performance-critical parts and use accessor functions for the rest [[#46508](https://github.com/apple/swift/issues/46508)].
A potential approach to stability mechanism is to provide metadata read/write functions alongside the runtime to interact with metadata, giving some freedom to the underlying structures to grow and change. This effectively makes large portions of metadata opaque. But, certain fields require access to be as efficient as possible (e.g. dynamic casts, calling into witness tables) and the performance hit from going through an intermediary function would be unacceptable. Thus, we will probably freeze the performance-critical parts and use accessor functions for the rest [[#46508](https://github.com/swiftlang/swift/issues/46508)].
Metadata has many historical artifacts in its representation that we want to clean up [[#46509](https://github.com/apple/swift/issues/46509)]. We also want to make small tweaks to present more semantic information in the metadata, to enable better future tooling and features such as reflection [[#46510](https://github.com/apple/swift/issues/46510)]. Some of these need to be done before declaring ABI stability and some may be additive.
Metadata has many historical artifacts in its representation that we want to clean up [[#46509](https://github.com/swiftlang/swift/issues/46509)]. We also want to make small tweaks to present more semantic information in the metadata, to enable better future tooling and features such as reflection [[#46510](https://github.com/swiftlang/swift/issues/46510)]. Some of these need to be done before declaring ABI stability and some may be additive.
#### Declaring Stability
Stabilizing the ABI means producing a precise technical specification for the fixed part of the metadata layout of all language constructs so that future compilers and tools can continue to read and write them. A prose description is not necessarily needed, though explanations are useful. We will also want to carve out extra space for areas where it is likely to be needed for future functionality [[#46316](https://github.com/apple/swift/issues/46316)].
Stabilizing the ABI means producing a precise technical specification for the fixed part of the metadata layout of all language constructs so that future compilers and tools can continue to read and write them. A prose description is not necessarily needed, though explanations are useful. We will also want to carve out extra space for areas where it is likely to be needed for future functionality [[#46316](https://github.com/swiftlang/swift/issues/46316)].
For more, but potentially out of date, details see the [Type Metadata docs](https://github.com/apple/swift/blob/main/docs/ABI/TypeMetadata.rst).
For more, but potentially out of date, details see the [Type Metadata docs](https://github.com/swiftlang/swift/blob/main/docs/ABI/TypeMetadata.rst).
### Generic Parameters
@@ -240,7 +240,7 @@ At run time, objects only have concrete types. If the type in source code is gen
### <a name="value-metadata"></a>Value Metadata
Named value types store the type name (currently mangled but we are investigating un-mangled [[#46511](https://github.com/apple/swift/issues/46511)]) and a pointer to the type's parent for nested types.
Named value types store the type name (currently mangled but we are investigating un-mangled [[#46511](https://github.com/swiftlang/swift/issues/46511)]) and a pointer to the type's parent for nested types.
Value type metadata also has kind-specific entries. Struct metadata stores information about its fields, field offsets, field names, and field metadata. Enum metadata stores information about its cases, payload sizes, and payload metadata. Tuple metadata stores information about its elements and labels.
@@ -248,21 +248,21 @@ Value type metadata also has kind-specific entries. Struct metadata stores infor
Every concrete type has a *value witness table* that provides information about how to lay out and manipulate values of that type. When a value type has [opaque layout](#opaque-layout), the actual layout and properties of that value type are not known at compilation time, so the value witness table is consulted.
The value witness table stores whether a type is trivial and/or bitwise movable, whether there are extra inhabitants and if so how to store and retrieve them, etc. For enums, the value witness table will also provide functionality for interacting with the discriminator. There may be more efficient ways of representing enums that simplify this functionality (or provide a fast path), and that's under investigation [[#46915](https://github.com/apple/swift/issues/46915)].
The value witness table stores whether a type is trivial and/or bitwise movable, whether there are extra inhabitants and if so how to store and retrieve them, etc. For enums, the value witness table will also provide functionality for interacting with the discriminator. There may be more efficient ways of representing enums that simplify this functionality (or provide a fast path), and that's under investigation [[#46915](https://github.com/swiftlang/swift/issues/46915)].
These value witness tables may be constructed statically for known values or dynamically for some generic values. While every unique type in Swift has a unique metadata pointer, value witness tables can be shared by types so long as the information provided is identical (i.e. same layout). Value witness tables always represent a type at its highest [abstraction level](#abstraction-levels). The value witness table entries and structure need to be locked down for ABI stability [[#46512](https://github.com/apple/swift/issues/46512)].
These value witness tables may be constructed statically for known values or dynamically for some generic values. While every unique type in Swift has a unique metadata pointer, value witness tables can be shared by types so long as the information provided is identical (i.e. same layout). Value witness tables always represent a type at its highest [abstraction level](#abstraction-levels). The value witness table entries and structure need to be locked down for ABI stability [[#46512](https://github.com/swiftlang/swift/issues/46512)].
### <a name="class-metadata"></a>Class Metadata
Swift class metadata is layout-compatible with Objective-C class objects on Apple's platforms, which places requirements on the contents of the first section of class metadata. In this first section, entries such as super class pointers, instance size, instance alignment, flags, and opaque data for the Objective-C runtime are stored.
Following that are superclass members, parent type metadata, generic parameter metadata, class members, and *vtables*, described below. Library evolution may present many changes to what exactly is present and will likely make many of the contents opaque to accommodate changes [[#46922](https://github.com/apple/swift/issues/46922)].
Following that are superclass members, parent type metadata, generic parameter metadata, class members, and *vtables*, described below. Library evolution may present many changes to what exactly is present and will likely make many of the contents opaque to accommodate changes [[#46922](https://github.com/swiftlang/swift/issues/46922)].
##### <a name="method-dispatch"></a>Method Dispatch
Invoking a non-final instance method involves calling a function that is not known at compile time: it must be resolved at run time. This is solved through the use of a *vtable*, or virtual method table (so called because overridable methods are also known as "virtual" methods). A *vtable* is a table of function pointers to a class or subclass's implementation of overridable methods. If the vtable is determined to be part of ABI, it needs a layout algorithm that also provides flexibility for library evolution.
Alternatively, we may decide to perform inter-module calls through opaque *thunks*, or compiler-created intermediary functions, which then perform either direct or vtable dispatch as needed [[#46513](https://github.com/apple/swift/issues/46513)]. This enables greater library evolution without breaking binary compatibility by allowing internal class hierarchies to change. This would also unify non-final method dispatch between open and non-open classes while still allowing for aggressive compiler optimizations like de-virtualization for non-open classes. This approach would make vtables not be ABI, as that part of the type metadata would effectively be opaque to another module.
Alternatively, we may decide to perform inter-module calls through opaque *thunks*, or compiler-created intermediary functions, which then perform either direct or vtable dispatch as needed [[#46513](https://github.com/swiftlang/swift/issues/46513)]. This enables greater library evolution without breaking binary compatibility by allowing internal class hierarchies to change. This would also unify non-final method dispatch between open and non-open classes while still allowing for aggressive compiler optimizations like de-virtualization for non-open classes. This approach would make vtables not be ABI, as that part of the type metadata would effectively be opaque to another module.
### Protocol and Existential Metadata
@@ -270,23 +270,23 @@ Alternatively, we may decide to perform inter-module calls through opaque *thunk
The protocol witness table is a function table of a type's conformance to the protocol's interfaces. If the protocol also has an associated type requirement, then the witness table will store the metadata for the associated type. Protocol witness tables are used with [existential containers](#existential-containers) where the run time type is not known.
Protocol witness tables may be created dynamically by the runtime or statically by the compiler. The layout of a protocol witness table is ABI and we need to determine a layout algorithm that also accommodates library evolution concerns, where additional protocol requirements may be added with default fall-backs [[#46317](https://github.com/apple/swift/issues/46317)].
Protocol witness tables may be created dynamically by the runtime or statically by the compiler. The layout of a protocol witness table is ABI and we need to determine a layout algorithm that also accommodates library evolution concerns, where additional protocol requirements may be added with default fall-backs [[#46317](https://github.com/swiftlang/swift/issues/46317)].
##### Existential Metadata
Existential type metadata contains the number of witness tables present, whether the type is class-constrained, and a *protocol descriptor* for each protocol constraint. A protocol descriptor describes an individual protocol constraint, such as whether it is class-constrained, the size of conforming witness tables, and protocol descriptors for any protocols it refines. Protocol descriptors are layout compatible with the Objective-C runtime's protocol records on Apple platforms. The format of the existential type metadata needs to be reviewed as part of the ABI definition [[#46920](https://github.com/apple/swift/issues/46920)].
Existential type metadata contains the number of witness tables present, whether the type is class-constrained, and a *protocol descriptor* for each protocol constraint. A protocol descriptor describes an individual protocol constraint, such as whether it is class-constrained, the size of conforming witness tables, and protocol descriptors for any protocols it refines. Protocol descriptors are layout compatible with the Objective-C runtime's protocol records on Apple platforms. The format of the existential type metadata needs to be reviewed as part of the ABI definition [[#46920](https://github.com/swiftlang/swift/issues/46920)].
### Function Metadata
In addition to common metadata entries, function type metadata stores information about the function signature: parameter and result type metadata, calling convention, per-parameter ownership conventions, and whether the function throws. Function type metadata always represents the function at its highest abstraction level, which is explained later in the [function signature lowering section](#lowering-higher-order-functions). Function parameters are currently modeled with a tuple-based design, but this should be updated to match modern Swift [[#46916](https://github.com/apple/swift/issues/46916)]. As more ownership semantics are modeled, more information may be stored about each parameter.
In addition to common metadata entries, function type metadata stores information about the function signature: parameter and result type metadata, calling convention, per-parameter ownership conventions, and whether the function throws. Function type metadata always represents the function at its highest abstraction level, which is explained later in the [function signature lowering section](#lowering-higher-order-functions). Function parameters are currently modeled with a tuple-based design, but this should be updated to match modern Swift [[#46916](https://github.com/swiftlang/swift/issues/46916)]. As more ownership semantics are modeled, more information may be stored about each parameter.
## <a name="mangling"></a>Mangling
Mangling is used to produce unique symbols. It applies to both external (public) symbols as well as internal or hidden symbols. Only the mangling scheme for external symbols is part of ABI.
ABI stability means a stable mangling scheme, fully specified so that future compilers and tools can honor it. For a potentially out-of-date specification of what the mangling currently looks like, see the [Name Mangling docs](https://github.com/apple/swift/blob/main/docs/ABI/Mangling.rst).
ABI stability means a stable mangling scheme, fully specified so that future compilers and tools can honor it. For a potentially out-of-date specification of what the mangling currently looks like, see the [Name Mangling docs](https://github.com/swiftlang/swift/blob/main/docs/ABI/Mangling.rst).
There are some corner cases currently in the mangling scheme that should be fixed before declaring ABI stability. We need to come up with a canonicalization of generic and protocol requirements to allow for order-agnostic mangling [[#46318](https://github.com/apple/swift/issues/46318)]. We also may decide to more carefully mangle variadicity of function parameters, etc [[#46319](https://github.com/apple/swift/issues/46319)]. Most often, though, mangling improvements focus on reducing symbol size.
There are some corner cases currently in the mangling scheme that should be fixed before declaring ABI stability. We need to come up with a canonicalization of generic and protocol requirements to allow for order-agnostic mangling [[#46318](https://github.com/swiftlang/swift/issues/46318)]. We also may decide to more carefully mangle variadicity of function parameters, etc [[#46319](https://github.com/swiftlang/swift/issues/46319)]. Most often, though, mangling improvements focus on reducing symbol size.
Mangling design centers around coming up with short and efficient manglings that still retain important properties such as uniqueness and integration with existing tools and formats. Given the prevalence of public symbols in libraries and frameworks, and debugging symbols in applications, the symbol names themselves can make up a significant portion of binary size. Reducing this impact is a major focus of stabilizing the mangling. Post-ABI-stability, any new manglings or techniques must be additive and must support the existing manglings.
@@ -294,23 +294,23 @@ There are many ways to improve the existing mangling without major impact on exi
### Compact Manglings
Minor tweaks to shorten the mangling can have a beneficial impact on all Swift program binary sizes. These tweaks should compact existing manglings while preserving a simple unique mapping. One example is not distinguishing between struct/enum in mangling structures, which would also provide more library evolution freedom [[#46515](https://github.com/apple/swift/issues/46515)]. We are considering dropping some internal witness table symbols when they don't provide any meaningful information conducive to debugging [[#46516](https://github.com/apple/swift/issues/46516)]. We recently overhauled word substitutions in mangling, with the goal of reducing as much redundancy in names as possible [[#46923](https://github.com/apple/swift/issues/46923)].
Minor tweaks to shorten the mangling can have a beneficial impact on all Swift program binary sizes. These tweaks should compact existing manglings while preserving a simple unique mapping. One example is not distinguishing between struct/enum in mangling structures, which would also provide more library evolution freedom [[#46515](https://github.com/swiftlang/swift/issues/46515)]. We are considering dropping some internal witness table symbols when they don't provide any meaningful information conducive to debugging [[#46516](https://github.com/swiftlang/swift/issues/46516)]. We recently overhauled word substitutions in mangling, with the goal of reducing as much redundancy in names as possible [[#46923](https://github.com/swiftlang/swift/issues/46923)].
There are other aggressive directions to investigate as well, such as mangling based on a known overload set for non-resilient functions. This does have the downside of making manglings unstable when new overloads are added, so its benefits would have to be carefully weighed [[#46518](https://github.com/apple/swift/issues/46518)].
There are other aggressive directions to investigate as well, such as mangling based on a known overload set for non-resilient functions. This does have the downside of making manglings unstable when new overloads are added, so its benefits would have to be carefully weighed [[#46518](https://github.com/swiftlang/swift/issues/46518)].
Any more ambitious reimagining of how to store symbols such as aggressive whole-library symbol name compression would have to be done in tight coupling with existing low level tools. Unfortunately, this might make some of the more ambitious options infeasible in time for ABI stability. They could be rolled out as ABI-additive using deployment target checking in the future.
### Suffix Differentiation
There are many existing low level tools and formats that store and consume the symbol information, and some of them use efficient storage techniques such as tries. Suffix differentiation is about adjusting the mangling in ways that take advantage of them: by distinguishing manglings through suffixes, i.e. having common shared prefixes. This is currently underway and is resulting in binary size reductions for platforms that use these techniques [[#46517](https://github.com/apple/swift/issues/46517)].
There are many existing low level tools and formats that store and consume the symbol information, and some of them use efficient storage techniques such as tries. Suffix differentiation is about adjusting the mangling in ways that take advantage of them: by distinguishing manglings through suffixes, i.e. having common shared prefixes. This is currently underway and is resulting in binary size reductions for platforms that use these techniques [[#46517](https://github.com/swiftlang/swift/issues/46517)].
## <a name="calling-convention"></a>Calling Convention
For the purposes of this document, "standard calling convention" refers to the C calling convention for a given platform (see [appendix](#platform-abis)), and "Swift calling convention" refers to the calling convention used by Swift code when calling other Swift code. One of the first steps toward ABI stability is for Swift to adopt the Swift calling convention [[#46925](https://github.com/apple/swift/issues/46925)]. The Swift runtime uses the standard calling convention, though it may make alterations (see section [Runtime calling convention](#runtime-calling-convention)).
For the purposes of this document, "standard calling convention" refers to the C calling convention for a given platform (see [appendix](#platform-abis)), and "Swift calling convention" refers to the calling convention used by Swift code when calling other Swift code. One of the first steps toward ABI stability is for Swift to adopt the Swift calling convention [[#46925](https://github.com/swiftlang/swift/issues/46925)]. The Swift runtime uses the standard calling convention, though it may make alterations (see section [Runtime calling convention](#runtime-calling-convention)).
Calling convention stability pertains to public interfaces. The Swift compiler is free to choose any convention for internal (intra-module) functions and calls.
For rationale and potentially-out-of-date details, see the [Swift Calling Convention Whitepaper](https://github.com/apple/swift/blob/main/docs/ABI/CallingConvention.rst). As part of nailing down the calling conventions, that document will either be updated with the final specifications of the calling conventions or else moved to a rationale document and a more succinct and rigorous specification put in its place.
For rationale and potentially-out-of-date details, see the [Swift Calling Convention Whitepaper](https://github.com/swiftlang/swift/blob/main/docs/ABI/CallingConvention.rst). As part of nailing down the calling conventions, that document will either be updated with the final specifications of the calling conventions or else moved to a rationale document and a more succinct and rigorous specification put in its place.
### Register convention
@@ -343,15 +343,15 @@ The specific registers used in these roles are documented in [the calling conven
Function signature lowering is the mapping of a function's source-language type, which includes formal parameters and results, all the way down to a physical convention, which dictates what values are stored in what registers and what values to pass on the stack.
ABI stability requires nailing down and fully specifying this algorithm so that future Swift versions can lower Swift types to the same physical call signature as prior Swift versions [[#46928](https://github.com/apple/swift/issues/46928)]. More in-depth descriptions and rationale of function signature lowering can be found in the [function signature lowering docs](https://github.com/apple/swift/blob/main/docs/ABI/CallingConvention.rst#function-signature-lowering).
ABI stability requires nailing down and fully specifying this algorithm so that future Swift versions can lower Swift types to the same physical call signature as prior Swift versions [[#46928](https://github.com/swiftlang/swift/issues/46928)]. More in-depth descriptions and rationale of function signature lowering can be found in the [function signature lowering docs](https://github.com/swiftlang/swift/blob/main/docs/ABI/CallingConvention.rst#function-signature-lowering).
Lowering the result value is usually done first, with a certain number of registers designated to hold the result value if it fits, otherwise the result value is passed on the stack. A good heuristic is needed for the limit and is architecture specific (e.g. 4 registers on modern 64-bit architectures) [[#46531](https://github.com/apple/swift/issues/46531)].
Lowering the result value is usually done first, with a certain number of registers designated to hold the result value if it fits, otherwise the result value is passed on the stack. A good heuristic is needed for the limit and is architecture specific (e.g. 4 registers on modern 64-bit architectures) [[#46531](https://github.com/swiftlang/swift/issues/46531)].
Next comes lowering parameters, which proceeds greedily by trying to fit values into registers from left-to-right, though some parameters may be re-ordered. For example, closures are best placed at the end to take advantage of ABI compatibility between thick closures and thin ones without a context.
Some values must be passed and returned indirectly as they are *address only*. Address only values include [non-bitwise-copyable](#type-properties) values, values with [opaque layout](#opaque-layout), and non-class-constrained [existential values](#existential-containers). Even if the runtime type would normally be passed in a register, or even if the type is statically known at the call-site, if the callee receives or returns values with opaque layout, they must be passed or returned indirectly.
We should investigate whether it makes sense to split values with partially opaque layout by passing the non-opaque parts in registers [[#46532](https://github.com/apple/swift/issues/46532)].
We should investigate whether it makes sense to split values with partially opaque layout by passing the non-opaque parts in registers [[#46532](https://github.com/swiftlang/swift/issues/46532)].
Parameter ownership is not reflected in the physical calling convention, though it will be noted in the mangling of the function name. Default argument expressions will not be ABI, as they will be emitted into the caller. This means that a library can add, modify, or remove default argument expressions without breaking binary compatibility (though modifying/removing may break source compatibility).
@@ -383,16 +383,16 @@ Such changes to runtime functions can be rolled out incrementally in the future,
Swift exposes a runtime that provides APIs for compiled code. Calls into the Swift runtime are produced by the compiler for concerns such as memory management and run-time type information. Additionally, the runtime exposes low-level reflection APIs that are useful to the standard library and some users.
Every existing runtime function will need to be audited for its desirability and behavior [[#46320](https://github.com/apple/swift/issues/46320)]. For every function, we need to evaluate whether we want the API as is:
Every existing runtime function will need to be audited for its desirability and behavior [[#46320](https://github.com/swiftlang/swift/issues/46320)]. For every function, we need to evaluate whether we want the API as is:
* If yes, then we need to precisely specify the semantics and guarantees of the API.
* If not, we need to either change, remove, or replace the API, and precisely specify the new semantics.
The runtime is also responsible for lazily creating new type metadata entries at run time, either for generic type instantiations or for resilient constructs. Library evolution in general introduces a whole new category of needs from the runtime by making data and metadata more opaque, requiring interaction to be done through runtime APIs. Additionally, ownership semantics may require new runtime APIs or modifications to existing APIs. These new runtime needs are still under investigation [[#46931](https://github.com/apple/swift/issues/46931)].
The runtime is also responsible for lazily creating new type metadata entries at run time, either for generic type instantiations or for resilient constructs. Library evolution in general introduces a whole new category of needs from the runtime by making data and metadata more opaque, requiring interaction to be done through runtime APIs. Additionally, ownership semantics may require new runtime APIs or modifications to existing APIs. These new runtime needs are still under investigation [[#46931](https://github.com/swiftlang/swift/issues/46931)].
There are many potential future directions to open up the ABI and operate on less-opaque data directly, as well as techniques such as call-site caching. These are ABI-additive, and will be interesting to explore in the future.
For a potentially-out-of-date listing of runtime symbols and some details, see the [Runtime docs](https://github.com/apple/swift/blob/main/docs/Runtime.md).
For a potentially-out-of-date listing of runtime symbols and some details, see the [Runtime docs](https://github.com/swiftlang/swift/blob/main/docs/Runtime.md).
## <a name="standard-library"></a>Standard Library
@@ -408,15 +408,15 @@ Any standard library API shipped post-ABI-stability must be supported into the f
Inlineable code that calls internal functions makes those internal functions ABI, as the client code will be making external calls to them. Thus, many internal interfaces in the standard library will need to be locked down if called from inlineable code. Whether to mark code inlineable will have to carefully weigh performance requirements against keeping flexibility for future changes.
This tradeoff between performance and flexibility also affects the ability to deploy bug fixes and performance improvements to users. Users that have inlined code from the standard library will not be able to get bug fixes and performance improvements in an OS update without performing a recompilation with the new library. For more information on this topic, see [Inlineable Functions](https://github.com/apple/swift/blob/main/docs/LibraryEvolution.rst#inlineable-functions).
This tradeoff between performance and flexibility also affects the ability to deploy bug fixes and performance improvements to users. Users that have inlined code from the standard library will not be able to get bug fixes and performance improvements in an OS update without performing a recompilation with the new library. For more information on this topic, see [Inlineable Functions](https://github.com/swiftlang/swift/blob/main/docs/LibraryEvolution.rst#inlineable-functions).
### Upcoming Changes
While the standard library is already ensuring source stability, it will be changing many of its fundamental underlying representations this year. When ABI stability lands, the standard library will be severely limited in the kinds of changes it can make to existing APIs and non-resilient types. Getting the standard library in the right place is of critical importance.
The programming model for String is still being redesigned [[#46933](https://github.com/apple/swift/issues/46933)], and many types such as Int are undergoing implementation changes [[#45784](https://github.com/apple/swift/issues/45784)]. At the same time, the standard library is simultaneously switching to new compiler features such as conditional conformances to clean up and deliver the best APIs [[#46046](https://github.com/apple/swift/issues/46046)].
The programming model for String is still being redesigned [[#46933](https://github.com/swiftlang/swift/issues/46933)], and many types such as Int are undergoing implementation changes [[#45784](https://github.com/swiftlang/swift/issues/45784)]. At the same time, the standard library is simultaneously switching to new compiler features such as conditional conformances to clean up and deliver the best APIs [[#46046](https://github.com/swiftlang/swift/issues/46046)].
Another goal of Swift is to improve the applicability of Swift to systems programming. Ownership semantics may make a large impact, including things such as improved `inout` semantics that allow for efficient and safe array slicing. Providing the right abstractions for efficient use of contiguous memory is still under investigation [[#46934](https://github.com/apple/swift/issues/46934)].
Another goal of Swift is to improve the applicability of Swift to systems programming. Ownership semantics may make a large impact, including things such as improved `inout` semantics that allow for efficient and safe array slicing. Providing the right abstractions for efficient use of contiguous memory is still under investigation [[#46934](https://github.com/swiftlang/swift/issues/46934)].
## Next Steps

2
docs/AccessControl.md
View File

@@ -26,7 +26,7 @@ framework module.
_**Warning**_
This document has not yet been updated for
[SE-0117](https://github.com/apple/swift-evolution/blob/main/proposals/0117-non-public-subclassable-by-default.md),
[SE-0117](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0117-non-public-subclassable-by-default.md),
which adds the \"open\" level of access.
## Rules

2
docs/Android.md
View File

@@ -8,7 +8,7 @@ device running Android or an emulator. This guide explains:
2. How to run the Swift test suite on an Android device.
If you encounter any problems following the instructions below, please
[file an issue](https://github.com/apple/swift/issues) and apply the "Android"
[file an issue](https://github.com/swiftlang/swift/issues) and apply the "Android"
label.
## FAQ

4
docs/Branches.md
View File

@@ -93,6 +93,6 @@ Some branches are *automerged* into other branches, to keep them in sync. This i
To update the Branch/Tag requirements, please follow these steps:
1. Create pull requests to update the branch/tag in the following repositories:
- in `apple/swift` modify [`update-checkout-config.json`](https://github.com/apple/swift/blob/main/utils/update_checkout/update-checkout-config.json)
- in `apple/swift-source-compat-suite` repository modify [`common.py`](https://github.com/apple/swift-source-compat-suite/blob/main/common.py)
- in `swiftlang/swift` modify [`update-checkout-config.json`](https://github.com/swiftlang/swift/blob/main/utils/update_checkout/update-checkout-config.json)
- in `swiftlang/swift-source-compat-suite` repository modify [`common.py`](https://github.com/swiftlang/swift-source-compat-suite/blob/main/common.py)
1. Notify @shahmishal after creating the pull requests

4
docs/ContinuousIntegration.md
View File

@@ -244,7 +244,7 @@ These commands will:
3. Compare the obtained data to the baseline (stored in git) and HEAD (version of a compiler built without the PR changes)
4. Report the results in a pull request comment
For the detailed explanation of how compiler performance is measured, please refer to [this document](https://github.com/apple/swift/blob/main/docs/CompilerPerformance.md).
For the detailed explanation of how compiler performance is measured, please refer to [this document](https://github.com/swiftlang/swift/blob/main/docs/CompilerPerformance.md).
## Cross Repository Testing
@@ -254,7 +254,7 @@ For example:
```
Please test with following pull request:
https://github.com/apple/swift/pull/4574
https://github.com/swiftlang/swift/pull/4574
@swift-ci Please test Linux platform
```

10
docs/CppInteroperability/CppInteroperabilityManifesto.md
View File

@@ -2,7 +2,7 @@
# ⚠️ Warning: document is out of date. ⚠️
**This document has not had significant updates in the last three years. The goals and design outlined here do not necessarily reflect those established by the C++ Interop Work Group. For an up-to-date document, please see [the Forward Vision document](https://github.com/apple/swift-evolution/blob/main/visions/using-swift-from-c%2B%2B.md).**
**This document has not had significant updates in the last three years. The goals and design outlined here do not necessarily reflect those established by the C++ Interop Work Group. For an up-to-date document, please see [the Forward Vision document](https://github.com/swiftlang/swift-evolution/blob/main/visions/using-swift-from-c%2B%2B.md).**
[** ‼️ Additionally, the official C++ interoperability documentation is live at Swift.org and provides an up-to-date guide for mixing Swift and C++ ‼️ **](https://www.swift.org/documentation/cxx-interop/)
@@ -280,7 +280,7 @@ func caller() {
To understand the constraints that Swift puts on `inout` parameters, let's take
a look at the mental model for introduced in the [Ownership
manifesto](OwnershipManifesto.md) and in [SE-0176 Enforce Exclusive Access to
Memory](https://github.com/apple/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md).
Memory](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md).
When the caller binds a storage reference to an `inout` parameter, it starts a
non-instantaneous access to the whole value that occupies the storage. This
access ends when the callee returns. Overlapping accesses are not allowed, and
@@ -1810,7 +1810,7 @@ dynamically, some are undefined behavior.
The backdoors are disallowed by the exclusivity rule (from [SE-0176 Enforce
Exclusive Access to
Memory](https://github.com/apple/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md)):
Memory](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md)):
> two accesses to the same variable are not allowed to overlap unless both
> accesses are reads
@@ -2881,7 +2881,7 @@ struct MyCxxCollection {
Swift has an equivalent for C++'s `operator()`: `callAsFunction` (introduced in
[SE-0253: Callable values of user-defined nominal
types](https://github.com/apple/swift-evolution/blob/main/proposals/0253-callable.md)).
types](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0253-callable.md)).
```c++
// C++ header.
@@ -3476,7 +3476,7 @@ A sidecar annotation file allows to add arbitrary attributes to declarations
parsed from a header file. You can find examples of such files in the [apinotes
directory](../apinotes). APINotes files
are handled by the [APINotes library in
Clang](https://github.com/apple/llvm-project/tree/apple/main/clang/lib/APINotes).
Clang](https://github.com/swiftlang/llvm-project/tree/apple/main/clang/lib/APINotes).
Clang reads an APINotes file alongside the header file; Clang injects attributes
specified by APINotes into the AST parsed from the header.

4
docs/CppInteroperability/CppInteroperabilityStatus.md
View File

@@ -77,7 +77,7 @@ This status table describes which of the following C++ language features can be
| Typedefs / Type aliases | Yes |
| Global Variables | Yes |
| Namespaces | Yes |
| Inline Namespaces | Yes, with some known issues ([#58217](https://github.com/apple/swift/issues/58217)) |
| Inline Namespaces | Yes, with some known issues ([#58217](https://github.com/swiftlang/swift/issues/58217)) |
| Exceptions | No. Uncaught exceptions that propagate into Swift frames are UB. |
| Fields | Yes |
| Member functions | Yes. Some value category overloads aren't imported |
@@ -121,7 +121,7 @@ This status table describes which of the following C++ standard library features
## Known Issues
### Inline Namespaces
- [#58217](https://github.com/apple/swift/issues/58217): 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
- [#58217](https://github.com/swiftlang/swift/issues/58217): 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/swiftlang/swift/blob/main/test/Interop/Cxx/namespace/inline-namespace-function-call-broken.swift
## Swift to C++ Interoperability Status

2
docs/CppInteroperability/GettingStartedWithC++Interop.md
View File

@@ -195,6 +195,6 @@ CxxInterop.main()
- To generate an Xcode project run `cmake -GXcode`
- To generate with Ninja run `cmake -GNinja`
- For more information on `cmake` see the 'GettingStarted' documentation: (https://github.com/apple/swift/blob/main/docs/HowToGuides/GettingStarted.md)
- For more information on `cmake` see the 'GettingStarted' documentation: (https://github.com/swiftlang/swift/blob/main/docs/HowToGuides/GettingStarted.md)

10
docs/DebuggingTheCompiler.md
View File

@@ -830,7 +830,7 @@ For more information and a high level example, see:
When bisecting it might be necessary to run the `update-checkout` script
each time you change shas. To do this you can pass `--match-timestamp`
to automatically checkout match the timestamp of the `apple/swift` repo
to automatically checkout match the timestamp of the `swiftlang/swift` repo
across the other repos.
## Disabling PCH Verification
@@ -859,7 +859,7 @@ such configuration.
# Debugging the Compiler Driver
The Swift compiler uses a standalone compiler-driver application written in
Swift: [swift-driver](https://github.com/apple/swift-driver). When building the
Swift: [swift-driver](https://github.com/swiftlang/swift-driver). When building the
compiler using `build-script`, by default, the standalone driver will be built
first, using the host toolchain, if the host toolchain contains a Swift
compiler. If the host toolchain does not contain Swift, a warning is emitted and
@@ -870,7 +870,7 @@ is updated with a symlink to the standalone driver, ensuring calls to the build
directory's `swift` and `swiftc` always forward to the standalone driver.
For more information about the driver, see:
[github.com/apple/swift-driver/blob/main/README.md](https://github.com/apple/swift-driver/blob/main/README.md)
[github.com/swiftlang/swift-driver/blob/main/README.md](https://github.com/swiftlang/swift-driver/blob/main/README.md)
## Swift Compiler Driver F.A.Q.
> What's the difference between invoking 'swiftc' vs. 'swift-driver' at the top
@@ -883,7 +883,7 @@ by examining the invoked program's name. The compiler frontend can be invoked
directly by invoking the `swift-frontend` executable, or passing in the
`-frontend` option to `swiftc`.
The standalone [Compiler Driver](https://github.com/apple/swift-driver) is
The standalone [Compiler Driver](https://github.com/swiftlang/swift-driver) is
installed as a separate `swift-driver` executable in the Swift toolchain's `bin`
directory. When a user launches the compiler by invoking `swiftc`, the C++ based
compiler executable forwards the invocation to the `swift-driver` executable if
@@ -905,7 +905,7 @@ become symbolic links to the `swift-driver` executable directly.
> Will 'swiftc ... -###' always print the same set of commands for the old/new
driver? Do they call 'swift-frontend' the same way?
The standalone [Compiler Driver](https://github.com/apple/swift-driver) is meant
The standalone [Compiler Driver](https://github.com/swiftlang/swift-driver) is meant
to be a direct drop-in replacement for the C++-based legacy driver. It has the
exact same command-line interface. The expectation is that its behaviour closely
matches the legacy driver; however, during, and after the transition to the new

2
docs/Diagnostics.md
View File

@@ -110,7 +110,7 @@ Educational notes should:
Adding new educational notes is a great way to get familiar with the process of contributing to Swift, while also making a big impact!
To add a new educational note:
1. Follow the [directions in the README](https://github.com/apple/swift#getting-sources-for-swift-and-related-projects) to checkout the Swift sources locally. Being able to build the Swift compiler is recommended, but not required, when contributing a new note.
1. Follow the [directions in the README](https://github.com/swiftlang/swift#getting-sources-for-swift-and-related-projects) to checkout the Swift sources locally. Being able to build the Swift compiler is recommended, but not required, when contributing a new note.
2. Identify a diagnostic to write an educational note for. To associate an educational note with a diagnostic name, you'll need to know its internal identifier. The easiest way to do this is to write a small program which triggers the diagnostic, and run it using the `-debug-diagnostic-names` compiler flag. This flag will cause the internal diagnostic identifier to be printed after the diagnostic message in square brackets.
3. Find any closely related diagnostics. Sometimes, what appears to be one diagnostic from a user's perspective may have multiple variations internally. After determining a diagnostic's internal identifier, run a search for it in the compiler source. You should find:
- An entry in a `Diagnostics*.def` file describing the diagnostic. If there are any closely related diagnostics the note should also be attached to, they can usually be found nearby.

42
docs/DifferentiableProgramming.md
View File

@@ -1071,7 +1071,7 @@ Besides numeric types, collections of numeric types are also powerful data
structures in differentiable programming. For example, the
[`Array`](https://developer.apple.com/documentation/swift/array) type in the
standard library
[conforms to `Differentiable`](https://github.com/apple/swift/blob/c224468653366119690aeb34f290843f3e5f2fd6/stdlib/public/core/Array.swift#L2052)
[conforms to `Differentiable`](https://github.com/swiftlang/swift/blob/c224468653366119690aeb34f290843f3e5f2fd6/stdlib/public/core/Array.swift#L2052)
conditionally when the `Element` type conforms to `Differentiable`. This makes
it possible to differentiate functions over arrays, and makes it easy to express
dynamic differentiable algorithms. Similarly, other common container types in
@@ -1861,9 +1861,9 @@ extension SIMDScalar where Self: Differentiable & BinaryFloatingPoint {
```
The full implementation is in
[`SIMDVector.swift`](https://github.com/apple/swift/blob/tensorflow/stdlib/public/core/SIMDVector.swift)
[`SIMDVector.swift`](https://github.com/swiftlang/swift/blob/tensorflow/stdlib/public/core/SIMDVector.swift)
and
[`SIMDVectorTypes.swift.gyb`](https://github.com/apple/swift/blob/tensorflow/stdlib/public/core/SIMDVectorTypes.swift.gyb)
[`SIMDVectorTypes.swift.gyb`](https://github.com/swiftlang/swift/blob/tensorflow/stdlib/public/core/SIMDVectorTypes.swift.gyb)
on the `tensorflow` branch.
#### Derivative functions
@@ -2012,7 +2012,7 @@ func foo<T: Differentiable, U, V: Differentiable>(
##### Examples
The `ElementaryFunctions` protocol introduced in
[SE-0246](https://github.com/apple/swift-evolution/blob/main/proposals/0246-mathable.md)
[SE-0246](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0246-mathable.md)
defines generic elementary functions, which are non-linear. By defining
derivatives using the `@derivative` attribute for these protocol
requirements in an extension, all conforming types now have differentiable
@@ -2607,19 +2607,19 @@ for _ in 0..<1000 {
Differential operators | Description
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -----------
[`transpose(of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L374) | Returns transpose of linear map.
[`valueWithDifferential(at:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L383) <br> [`valueWithDifferential(at:_:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L390) (arity 2) | Returns original result and differential function.
[`valueWithPullback(at:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L276) <br> [`valueWithPullback(at:_:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L283) | Returns original result and pullback function.
[`differential(at:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L435) <br> [`differential(at:_:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L442) (arity 2) | Returns differential function.
[`pullback(at:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L302) <br> [`pullback(at:_:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L309) | Returns pullback function.
[`derivative(at:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L483) <br> [`derivative(at:_:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L491) (arity 2) | Returns partial derivatives with respect to arguments ("forward-mode").
[`gradient(at:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L384) <br> [`gradient(at:_:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L392) | Returns partial derivatives with respect to arguments ("reverse-mode").
[`valueWithDerivative(at:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L538) <br> [`valueWithDerivative(at:_:of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L547) (arity 2) | Returns original result and partial derivatives with respect to arguments ("forward-mode").
[`valueWithGradient(at:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L327) <br> [`valueWithGradient(at:_:of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L335) | Returns original result and partial derivatives with respect to arguments ("reverse-mode").
[`derivative(of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L601) <br> [`derivative(of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L609) (arity 2) | Returns derivative function, taking original arguments and returning and partial derivatives with respect to arguments ("forward-mode").
[`gradient(of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L410) <br> [`gradient(of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L418) | Returns gradient function, taking original arguments and returning and partial derivatives with respect to arguments ("reverse-mode").
[`valueWithDerivative(of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L656) <br> [`valueWithDerivative(of:)`](https://github.com/apple/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L664) (arity 2) | Returns function taking original arguments and returning original result and partial derivatives with respect to arguments ("forward-mode").
[`valueWithGradient(of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L356) <br> [`valueWithGradient(of:)`](https://github.com/apple/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L364) | Returns function taking original arguments and returning original result and partial derivatives with respect to arguments ("reverse-mode").
[`transpose(of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L374) | Returns transpose of linear map.
[`valueWithDifferential(at:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L383) <br> [`valueWithDifferential(at:_:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L390) (arity 2) | Returns original result and differential function.
[`valueWithPullback(at:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L276) <br> [`valueWithPullback(at:_:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L283) | Returns original result and pullback function.
[`differential(at:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L435) <br> [`differential(at:_:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L442) (arity 2) | Returns differential function.
[`pullback(at:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L302) <br> [`pullback(at:_:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L309) | Returns pullback function.
[`derivative(at:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L483) <br> [`derivative(at:_:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L491) (arity 2) | Returns partial derivatives with respect to arguments ("forward-mode").
[`gradient(at:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L384) <br> [`gradient(at:_:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L392) | Returns partial derivatives with respect to arguments ("reverse-mode").
[`valueWithDerivative(at:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L538) <br> [`valueWithDerivative(at:_:of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L547) (arity 2) | Returns original result and partial derivatives with respect to arguments ("forward-mode").
[`valueWithGradient(at:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L327) <br> [`valueWithGradient(at:_:of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L335) | Returns original result and partial derivatives with respect to arguments ("reverse-mode").
[`derivative(of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L601) <br> [`derivative(of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L609) (arity 2) | Returns derivative function, taking original arguments and returning and partial derivatives with respect to arguments ("forward-mode").
[`gradient(of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L410) <br> [`gradient(of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L418) | Returns gradient function, taking original arguments and returning and partial derivatives with respect to arguments ("reverse-mode").
[`valueWithDerivative(of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L656) <br> [`valueWithDerivative(of:)`](https://github.com/swiftlang/swift/blob/9c95e27601e9623f5b53c9cc531d185e267a83d6/stdlib/public/core/AutoDiff.swift#L664) (arity 2) | Returns function taking original arguments and returning original result and partial derivatives with respect to arguments ("forward-mode").
[`valueWithGradient(of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L356) <br> [`valueWithGradient(of:)`](https://github.com/swiftlang/swift/blob/c1211a3f78992c89a3ab4d638c378c6f45ab8fe8/stdlib/public/core/AutoDiff.swift#L364) | Returns function taking original arguments and returning original result and partial derivatives with respect to arguments ("reverse-mode").
#### Static analysis
@@ -3108,7 +3108,7 @@ Parker Schuh, and Dimitrios Vytiniotis.
[Bart Chrzaszcz]: https://github.com/bartchr808
[swift-numerics]: https://github.com/apple/swift-numerics
[SE-0229]: https://github.com/apple/swift-evolution/blob/main/proposals/0229-simd.md
[SE-0233]: https://github.com/apple/swift-evolution/blob/main/proposals/0233-additive-arithmetic-protocol.md
[SE-0246]: https://github.com/apple/swift-evolution/blob/main/proposals/0246-mathable.md
[SE-0251]: https://github.com/apple/swift-evolution/blob/main/proposals/0251-simd-additions.md
[SE-0229]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0229-simd.md
[SE-0233]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0233-additive-arithmetic-protocol.md
[SE-0246]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0246-mathable.md
[SE-0251]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0251-simd-additions.md

22
docs/DifferentiableProgrammingImplementation.md
View File

@@ -241,7 +241,7 @@ let diffFunction: @differentiable (Float) -> Float = function
Differentiable function types are a subtype of normal function types. See [here](DifferentiableProgramming.md#function-subtyping-and-runtime-representation) for more information about type checking rules.
Differentiable function conversion is represented in the AST as an explicit [DifferentiableFunctionExpr](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/include/swift/AST/Expr.h#L2923) expression. Example output from `swiftc -dump-ast` for the explicit conversion example above:
Differentiable function conversion is represented in the AST as an explicit [DifferentiableFunctionExpr](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/include/swift/AST/Expr.h#L2923) expression. Example output from `swiftc -dump-ast` for the explicit conversion example above:
```
(differentiable_function implicit
@@ -793,15 +793,15 @@ Many of these instructions have well-defined corresponding tangent instructions
| Original | Tangent (differential) | Adjoint (pullback)
| -------- | ---------------------- | ------------------
| `y = load x` | `tan[y] = load tan[x]` | `adj[x] += adj[y]` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5346)
| `store x to y` | `store tan[x] to tan[y]` | `adj[x] += load adj[y]; adj[y] = 0` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5365)
| `copy_addr x to y` | `copy_addr tan[x] to tan[y]` | `adj[x] += adj[y]; adj[y] = 0` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5382)
| `y = struct (x0, x1, ...)` | `tan[y] = struct (tan[x0], tan[x1], ...)` | `adj[x0] += struct_extract adj[y], #x0` `adj[x1] += struct_extract adj[y], #x1` `...` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5110)
| `y = struct_extract x, #field` | `tan[y] = struct_extract tan[x], #field’` | `adj[x] += struct (0, ..., #field': adj[y], ..., 0)` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5183)
| `y = struct_element_addr x, #field` | `tan[y] = struct_element_addr tan[x], #field’` | No generated code. `adj[y] = struct_element_addr adj[x], #field’` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L4157)
| `y = tuple (x0, x1, ...)` | `tan[y] = tuple (tan[x0], tan[x1], ...)` | `adj[x0] += tuple_extract adj[y], 0` `adj[x1] += tuple_extract adj[y], 1` `...` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5257)
| `y = tuple_extract x, <n>` | `tan[y] = tuple_extract tan[x], <n’>` | `adj[x] += tuple (0, ..., adj[y], ..., 0)` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5298)
| `y = tuple_element_addr x, <n>` | `tan[y] = tuple_element_addr tan[x], <n’>` | No generated code. `adj[y] = tuple_element_addr adj[x], <n’>` [(code)](https://github.com/apple/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L4169)
| `y = load x` | `tan[y] = load tan[x]` | `adj[x] += adj[y]` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5346)
| `store x to y` | `store tan[x] to tan[y]` | `adj[x] += load adj[y]; adj[y] = 0` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5365)
| `copy_addr x to y` | `copy_addr tan[x] to tan[y]` | `adj[x] += adj[y]; adj[y] = 0` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5382)
| `y = struct (x0, x1, ...)` | `tan[y] = struct (tan[x0], tan[x1], ...)` | `adj[x0] += struct_extract adj[y], #x0` `adj[x1] += struct_extract adj[y], #x1` `...` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5110)
| `y = struct_extract x, #field` | `tan[y] = struct_extract tan[x], #field’` | `adj[x] += struct (0, ..., #field': adj[y], ..., 0)` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5183)
| `y = struct_element_addr x, #field` | `tan[y] = struct_element_addr tan[x], #field’` | No generated code. `adj[y] = struct_element_addr adj[x], #field’` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L4157)
| `y = tuple (x0, x1, ...)` | `tan[y] = tuple (tan[x0], tan[x1], ...)` | `adj[x0] += tuple_extract adj[y], 0` `adj[x1] += tuple_extract adj[y], 1` `...` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5257)
| `y = tuple_extract x, <n>` | `tan[y] = tuple_extract tan[x], <n’>` | `adj[x] += tuple (0, ..., adj[y], ..., 0)` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L5298)
| `y = tuple_element_addr x, <n>` | `tan[y] = tuple_element_addr tan[x], <n’>` | No generated code. `adj[y] = tuple_element_addr adj[x], <n’>` [(code)](https://github.com/swiftlang/swift/blob/8b7ab1143e260d7bb1db3b98e24f7fe28dc7f0f0/lib/SILOptimizer/Mandatory/Differentiation.cpp#L4169)
In general, tangent transformation rules are simpler because the tangent transformation does not involve control flow reversal and because many instructions themselves are linear.
@@ -962,7 +962,7 @@ This involves:
- Adding a JVP/VJP type calculation special case for reabstraction thunks.
- Changing the differentiation transform so that reabstraction thunk JVP/VJP callers always construct and pass a `@differentiable` function-typed value.
This approach is implemented in https://github.com/apple/swift/pull/28570. A partially-applied reabstraction thunk derivative matches the derivative type of the reabstracted original function.
This approach is implemented in https://github.com/swiftlang/swift/pull/28570. A partially-applied reabstraction thunk derivative matches the derivative type of the reabstracted original function.
Alternatives:
- Make reabstraction thunk JVPs/VJPs take a "JVP/VJP" function-typed argument instead of a `@differentiable` function-typed argument.

2
docs/DocumentationComments.md
View File

@@ -5,7 +5,7 @@ comments utilize a full-fledged [CommonMark] parser library (known as [swift-cma
the Swift projects), which is rendered in Xcode QuickHelp.
[CommonMark]: http://commonmark.org
[cmark]: https://github.com/apple/swift-cmark
[cmark]: https://github.com/swiftlang/swift-cmark
Swift Markup syntax is *exactly* CommonMark, *by design*, not only for its
straightforward implementation and completeness but also in the spirit of

10
docs/Driver.md
View File

@@ -167,7 +167,7 @@ The output file map accepts other entries, but they should not be considered
stable. Please stick to what's shown here.
(Note: In the example output file map above, all of the per-file outputs are
being emitted to the same directory. [#42949](https://github.com/apple/swift/issues/42949)
being emitted to the same directory. [#42949](https://github.com/swiftlang/swift/issues/42949)
covers adding a flag that would infer this behavior given a directory path.)
@@ -284,8 +284,8 @@ past that, so:
import later.
If you want debugging that's more than `-gline-tables-only`, this is the
only supported way to do it today [apple/llvm-project#4588](https://github.com/apple/llvm-project/issues/4588)
and [#45265](https://github.com/apple/swift/issues/45265) are aimed at
only supported way to do it today [swiftlang/llvm-project#4588](https://github.com/swiftlang/llvm-project/issues/4588)
and [#45265](https://github.com/swiftlang/swift/issues/45265) are aimed at
improving on this). On the plus side, this mode doesn't strictly need an
output file map if you give up incremental builds.
@@ -302,7 +302,7 @@ _Can I link all the object files together in the same binary, even if they came
from multiple modules?_
This is not currently supported, and debugging probably won't work (see
[apple/llvm-project#4588](https://github.com/apple/llvm-project/issues/4588) and
[#45265](https://github.com/apple/swift/issues/45265) for more details).
[swiftlang/llvm-project#4588](https://github.com/swiftlang/llvm-project/issues/4588) and
[#45265](https://github.com/swiftlang/swift/issues/45265) for more details).
However, if you are using `-gnone` or `-gline-tables-only`, the worst you will
suffer is more symbols being visible than are strictly necessary.

12
docs/DynamicCasting.md
View File

@@ -1,7 +1,7 @@
# Dynamic Casting Behavior
* Author: [Tim Kientzle](https://github.com/tbkka)
* Implementation: [apple/swift#29658](https://github.com/apple/swift/pull/29658)
* Implementation: [swiftlang/swift#29658](https://github.com/swiftlang/swift/pull/29658)
## Introduction
@@ -665,7 +665,7 @@ let a = NSNumber()
print(a is Any)
```
* [#44896](https://github.com/apple/swift/issues/44896): CF types cannot be cast to protocol existentials
* [#44896](https://github.com/swiftlang/swift/issues/44896): CF types cannot be cast to protocol existentials
```swift
import Foundation
@@ -680,7 +680,7 @@ extension CFBitVector : P {
print(CFBitVector.makeImmutable(from: [10,20]) is P)
```
* [#47129](https://github.com/apple/swift/issues/47129): Cannot cast `Optional<T> as Any` to protocol type. Note that this is a particular problem for reflection with weak fields, since `Mirror` reflects those as `Any` containing an `Optional` value.
* [#47129](https://github.com/swiftlang/swift/issues/47129): Cannot cast `Optional<T> as Any` to protocol type. Note that this is a particular problem for reflection with weak fields, since `Mirror` reflects those as `Any` containing an `Optional` value.
```swift
protocol P {}
@@ -692,7 +692,7 @@ let a = c as? Any
print(a is P)
```
* [#51469](https://github.com/apple/swift/issues/51469): `Any` containing `Optional<Any>` cannot cast to `Error`
* [#51469](https://github.com/swiftlang/swift/issues/51469): `Any` containing `Optional<Any>` cannot cast to `Error`
```swift
struct MyError: Error { }
@@ -703,7 +703,7 @@ let b: Any = a
print(b is Error)
```
* [#48681](https://github.com/apple/swift/issues/48681): Inconsistent results for nested optionals
* [#48681](https://github.com/swiftlang/swift/issues/48681): Inconsistent results for nested optionals
```swift
// Note: This issue includes many cases similar to the following
@@ -730,7 +730,7 @@ let a = NSObjectProtocol.self
print(a is NSObjectProtocol.Type)
```
* [#44608](https://github.com/apple/swift/issues/44608): Cannot cast `Any` contents to a protocol type
* [#44608](https://github.com/swiftlang/swift/issues/44608): Cannot cast `Any` contents to a protocol type
```swift
protocol P {}

2
docs/EmbeddedSwift/ABI.md
View File

@@ -4,7 +4,7 @@
**‼️ Use the latest downloadable 'Trunk Development' snapshot from swift.org to use Embedded Swift. Public releases of Swift do not yet support Embedded Swift.**
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
## ABI stability

2
docs/EmbeddedSwift/EmbeddedSwiftStatus.md
View File

@@ -4,7 +4,7 @@
**‼️ Use the latest downloadable 'Trunk Development' snapshot from swift.org to use Embedded Swift. Public releases of Swift do not yet support Embedded Swift.**
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
## Embedded Swift Language Features

2
docs/EmbeddedSwift/IntegratingWithSDKs.md
View File

@@ -4,7 +4,7 @@
**‼️ Use the latest downloadable 'Trunk Development' snapshot from swift.org to use Embedded Swift. Public releases of Swift do not yet support Embedded Swift.**
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
The following document sketches how to integrate Swift code into some popular embedded platforms' SDKs and build systems.

2
docs/EmbeddedSwift/UserManual.md
View File

@@ -4,7 +4,7 @@
**‼️ Use the latest downloadable 'Trunk Development' snapshot from swift.org to use Embedded Swift. Public releases of Swift do not yet support Embedded Swift.**
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
The following document explains how to use Embedded Swift's support in the Swift compiler and toolchain.

26
docs/GenericsManifesto.md
View File

@@ -8,7 +8,7 @@ The "Complete Generics" goal for Swift 3 has been fairly ill-defined thus far, w
This message expands upon the notion of "completing generics". It is not a plan for Swift 3, nor an official core team communication, but it collects the results of numerous discussions among the core team and Swift developers, both of the compiler and the standard library. I hope to achieve several things:
* **Communicate a vision for Swift generics**, building on the [original generics design document](https://github.com/apple/swift/blob/main/docs/archive/Generics.rst), so we have something concrete and comprehensive to discuss.
* **Communicate a vision for Swift generics**, building on the [original generics design document](https://github.com/swiftlang/swift/blob/main/docs/archive/Generics.rst), so we have something concrete and comprehensive to discuss.
* **Establish some terminology** that the Swift developers have been using for these features, so our discussions can be more productive ("oh, you're proposing what we refer to as 'conditional conformances'; go look over at this thread").
@@ -27,7 +27,7 @@ There are a number of restrictions to the use of generics that fall out of the i
### Recursive protocol constraints (*)
*This feature has been accepted in [SE-0157](https://github.com/apple/swift-evolution/blob/main/proposals/0157-recursive-protocol-constraints.md) and was released with Swift 4.1.*
*This feature has been accepted in [SE-0157](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0157-recursive-protocol-constraints.md) and was released with Swift 4.1.*
Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For example, in the standard library `SubSequence` type of a `Sequence` should itself be a `Sequence`:
@@ -43,7 +43,7 @@ The compiler currently rejects this protocol, which is unfortunate: it effective
### Nested generics
*This feature was tracked by [#44055](https://github.com/apple/swift/issues/44055) and was released with Swift 3.1.*
*This feature was tracked by [#44055](https://github.com/swiftlang/swift/issues/44055) and was released with Swift 3.1.*
Currently, a generic type cannot be nested within another generic type, e.g.
@@ -57,7 +57,7 @@ There isn't much to say about this: the compiler simply needs to be improved to
### Concrete same-type requirements
*This feature was tracked by [#43621](https://github.com/apple/swift/issues/43621) and was released with Swift 3.1.*
*This feature was tracked by [#43621](https://github.com/swiftlang/swift/issues/43621) and was released with Swift 3.1.*
Currently, a constrained extension cannot use a same-type constraint to make a type parameter equivalent to a concrete type. For example:
@@ -77,7 +77,7 @@ There are a number of Swift declarations that currently cannot have generic para
### Generic typealiases
*This feature has been accepted in [SE-0048](https://github.com/apple/swift-evolution/blob/main/proposals/0048-generic-typealias.md) and was released with Swift 3.*
*This feature has been accepted in [SE-0048](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0048-generic-typealias.md) and was released with Swift 3.*
Typealiases could be allowed to carry generic parameters. They would still be aliases (i.e., they would not introduce new types). For example:
@@ -114,7 +114,7 @@ Note: generic associatedtypes address many use cases also addressed by higher-ki
### Generic subscripts
*This feature has been accepted in [SE-0148](https://github.com/apple/swift-evolution/blob/main/proposals/0148-generic-subscripts.md), was tracked by [#42737](https://github.com/apple/swift/issues/42737) and was released with Swift 4.*
*This feature has been accepted in [SE-0148](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0148-generic-subscripts.md), was tracked by [#42737](https://github.com/swiftlang/swift/issues/42737) and was released with Swift 4.*
Subscripts could be allowed to have generic parameters. For example, we could introduce a generic subscript on a `Collection` that allows us to pull out the values at an arbitrary set of indices:
@@ -210,7 +210,7 @@ There are a number of minor extensions we can make to the generics system that d
### Arbitrary requirements in protocols (*)
*This feature has been accepted in [SE-0142](https://github.com/apple/swift-evolution/blob/main/proposals/0142-associated-types-constraints.md) and was released with Swift 4.*
*This feature has been accepted in [SE-0142](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0142-associated-types-constraints.md) and was released with Swift 4.*
Currently, a new protocol can inherit from other protocols, introduce new associated types, and add new conformance constraints to associated types (by redeclaring an associated type from an inherited protocol). However, one cannot express more general constraints. Building on the example from "Recursive protocol constraints", we really want the element type of a `Sequence`'s `SubSequence` to be the same as the element type of the `Sequence`, e.g.,
@@ -226,7 +226,7 @@ Hanging the `where` clause off the associated type protocol is not ideal, but th
### Typealiases in protocols and protocol extensions (*)
*This feature has been accepted in [SE-0092](https://github.com/apple/swift-evolution/blob/main/proposals/0092-typealiases-in-protocols.md) and was released with Swift 3.*
*This feature has been accepted in [SE-0092](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0092-typealiases-in-protocols.md) and was released with Swift 3.*
Now that associated types have their own keyword (thanks!), it's reasonable to bring back `typealias`. Again with the `Sequence` protocol:
@@ -253,7 +253,7 @@ var p3: Promise = getRandomPromise() // p3 has type Promise<Int, Error> due to t
### Generalized `class` constraints
*This feature is a consequence of proposal [SE-0156](https://github.com/apple/swift-evolution/blob/main/proposals/0156-subclass-existentials.md) and was released with Swift 4.*
*This feature is a consequence of proposal [SE-0156](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0156-subclass-existentials.md) and was released with Swift 4.*
The `class` constraint can currently only be used for defining protocols. We could generalize it to associated type and type parameter declarations, e.g.,
@@ -322,7 +322,7 @@ Unlike the minor extensions, major extensions to the generics model provide more
### Conditional conformances (*)
*This feature has been accepted in [SE-0143](https://github.com/apple/swift-evolution/blob/main/proposals/0143-conditional-conformances.md) and is implemented in Swift 4.2.*
*This feature has been accepted in [SE-0143](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0143-conditional-conformances.md) and is implemented in Swift 4.2.*
Conditional conformances express the notion that a generic type will conform to a particular protocol only under certain circumstances. For example, `Array` is `Equatable` only when its elements are `Equatable`:
@@ -496,7 +496,7 @@ extension Bag {
### Moving the `where` clause outside of the angle brackets (*)
*Accepted in [SE-0081](https://github.com/apple/swift-evolution/blob/main/proposals/0081-move-where-expression.md) and implemented in Swift 3.*
*Accepted in [SE-0081](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0081-move-where-expression.md) and implemented in Swift 3.*
The `where` clause of generic functions comes very early in the declaration, although it is generally of much less concern to the client than the function parameters and result type that follow it. This is one of the things that contributes to "angle bracket blindness". For example, consider the `containsAll` signature above:
@@ -513,7 +513,7 @@ func containsAll<S: Sequence>(elements: S) -> Bool
### Renaming `protocol<...>` to `Any<...>` (*)
*Accepted in [SE-0095](https://github.com/apple/swift-evolution/blob/main/proposals/0095-any-as-existential.md) as "Replace `protocol<P1,P2>` syntax with `P1 & P2` syntax" and implemented in Swift 3.*
*Accepted in [SE-0095](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0095-any-as-existential.md) as "Replace `protocol<P1,P2>` syntax with `P1 & P2` syntax" and implemented in Swift 3.*
The `protocol<...>` syntax is a bit of an oddity in Swift. It is used to compose protocols together, mostly to create values of existential type, e.g.,
@@ -730,7 +730,7 @@ The generics system doesn't seem like a good candidate for a reduction in scope;
### Associated type inference
*[SE-0108](https://github.com/apple/swift-evolution/blob/main/proposals/0108-remove-assoctype-inference.md), a proposal to remove this feature, was rejected.*
*[SE-0108](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0108-remove-assoctype-inference.md), a proposal to remove this feature, was rejected.*
Associated type inference is the process by which we infer the type bindings for associated types from other requirements. For example:

2
docs/HowSwiftImportsCAPIs.md
View File

@@ -958,7 +958,7 @@ Swift enums.
The concept of open enums was added in Swift 5 ([SE-0192 Handling Future
Enum
Cases](https://github.com/apple/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md)),
Cases](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md)),
but that proposal did not change the importing strategy of non-annotated C
enums, in part because of source compatibility concerns. It might be still
possible to change C enums to be imported as open Swift enums, but as the time

2
docs/HowToGuides/FAQ.md
View File

@@ -99,7 +99,7 @@ This compiles the `.rst` files in the `docs` directory into HTML in the
For the Markdown documentation, you can view the rendered HTML directly on
GitHub. For example, this file is rendered on GitHub at
https://github.com/apple/swift/tree/main/docs/HowToGuides/FAQ.md .
https://github.com/swiftlang/swift/tree/main/docs/HowToGuides/FAQ.md .
HTML documentation for the standard library on Darwin platforms is hosted on the
[Apple Developer website](https://developer.apple.com/documentation/swift/swift_standard_library).

2
docs/LSANFailureSymbolication.md
View File

@@ -2,7 +2,7 @@
### Create Ubuntu Container
1. Clone (or pull) swift-docker: https://github.com/apple/swift-docker
1. Clone (or pull) swift-docker: https://github.com/swiftlang/swift-docker
2. Build the Ubuntu 18.04 container: `cd swift-ci/master/ubuntu/18.04; docker build .`
3. `docker run -it --cpus <CPUs> --memory <Memory> -v ~/<path to your local sources>:/src-on-host:cached --name lsan-reproducer --cap-add=SYS_PTRACE --security-opt seccomp=unconfined <hash that docker build outputs> bash`
- The `-cap-add` and `-security-opt` arguments are needed to run LLDB inside the Docker container

6
docs/LibraryEvolution.rst
View File

@@ -29,7 +29,7 @@ Library evolution was formally described in `SE-0260 <SE0260_>`_, but this
document should be kept up to date as new features are added to the language.
.. _library evolution: https://swift.org/blog/abi-stability-and-more/
.. _SE0260: https://github.com/apple/swift-evolution/blob/main/proposals/0260-library-evolution.md
.. _SE0260: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0260-library-evolution.md
.. contents:: :local:
@@ -108,7 +108,7 @@ with a single app target are not forced to think about access control, anyone
writing a bundled library should (ideally) not be required to use any of the
annotations described below in order to achieve full performance.
.. _SE0193: https://github.com/apple/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md
.. _SE0193: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md
.. _Swift Package Manager: https://swift.org/package-manager/
.. note::
@@ -218,7 +218,7 @@ any future use of the function must take this into account.
Although they are not a supported feature for arbitrary libraries at this time,
public `transparent`_ functions are implicitly marked ``@inlinable``.
.. _transparent: https://github.com/apple/swift/blob/main/docs/TransparentAttr.md
.. _transparent: https://github.com/swiftlang/swift/blob/main/docs/TransparentAttr.md
Restrictions on Inlinable Functions

2
docs/LibraryEvolutionManifesto.md
View File

@@ -122,7 +122,7 @@ Both of these annotations are things the compiler already knows when a type is d
The compiler actually has basic support for frozen classes, which allow stored properties to be accessed directly by offset from the class reference. There's no real reason why this can't be supported more generally, but confusion around *what's* being frozen and the rarity of wanting to make this promise anyway kept it out of [SE-0260][].
[SE-0260]: https://github.com/apple/swift-evolution/blob/main/proposals/0260-library-evolution.md
[SE-0260]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0260-library-evolution.md
# Generalized Availability Model

6
docs/OpenBSD.md
View File

@@ -41,9 +41,9 @@ Download the sources with the [Getting Started](/docs/HowToGuides/GettingStarted
"https-clone-pattern": "https://github.com/%s.git",
"default-branch-scheme": "main",
"repos": {
"cmark": { "remote": { "id": "apple/swift-cmark" } },
"llvm-project": { "remote": { "id": "apple/llvm-project" } },
"swift": { "remote": { "id": "apple/swift" } }
"cmark": { "remote": { "id": "swiftlang/swift-cmark" } },
"llvm-project": { "remote": { "id": "swiftlang/llvm-project" } },
"swift": { "remote": { "id": "swiftlang/swift" } }
},
"branch-schemes": {
"main": {

2
docs/OptimizationTips.rst
View File

@@ -548,7 +548,7 @@ alive.
}
.. _Unmanaged.swift: https://github.com/apple/swift/blob/main/stdlib/public/core/Unmanaged.swift
.. _Unmanaged.swift: https://github.com/swiftlang/swift/blob/main/stdlib/public/core/Unmanaged.swift
Protocols
=========

4
docs/README.md
View File

@@ -270,11 +270,11 @@ documentation, please create a thread on the Swift forums under the
### Proposals
Old proposals are present in the [/docs/proposals](/docs/proposals) directory.
More recent proposals are located in the [apple/swift-evolution][] repository.
More recent proposals are located in the [swiftlang/swift-evolution][] repository.
You can see the status of different proposals at
<https://apple.github.io/swift-evolution/>.
[apple/swift-evolution]: https://github.com/apple/swift-evolution
[swiftlang/swift-evolution]: https://github.com/swiftlang/swift-evolution
### Surveys

6
docs/ReferenceGuides/UnderscoredAttributes.md
View File

@@ -53,7 +53,7 @@ Adding this attribute to a type leads to remarks being emitted for all methods.
## `@_backDeploy(before: ...)`
The spelling of `@backDeployed(before:)` prior to the acceptance of [SE-0376](https://github.com/apple/swift-evolution/blob/main/proposals/0376-function-back-deployment.md).
The spelling of `@backDeployed(before:)` prior to the acceptance of [SE-0376](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0376-function-back-deployment.md).
## `@_borrowed`
@@ -658,7 +658,7 @@ also work as a generic type constraint.
Indicates that a protocol is a marker protocol. Marker protocols represent some
meaningful property at compile-time but have no runtime representation.
For more details, see [](https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md#marker-protocols), which introduces marker protocols.
For more details, see [](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md#marker-protocols), which introduces marker protocols.
At the moment, the language only has one marker protocol: `Sendable`.
Fun fact: Rust has a very similar concept called
@@ -1111,7 +1111,7 @@ if so, it is assumed that the function/global is implemented in C.
A function defined by `@_silgen_name` is assumed to use the Swift ABI.
For more details, see the
[Standard Library Programmer's Manual](https://github.com/apple/swift/blob/main/docs/StandardLibraryProgrammersManual.md#_silgen_name).
[Standard Library Programmer's Manual](https://github.com/swiftlang/swift/blob/main/docs/StandardLibraryProgrammersManual.md#_silgen_name).
## `@_specialize(...)`

12
docs/RequestEvaluator.md
View File

@@ -1,10 +1,10 @@
# Request-Evaluator
The [request-evaluator](https://github.com/apple/swift/blob/main/include/swift/AST/Evaluator.h) is a new architectural approach for the Swift compiler that attempts to provide infrastructure for fine-grained tracking and visualization of dependencies, separately caching the results of computation within the compiler, and eliminating mutable state, particular from the Abstract Syntax Tree (AST). It is intended to address a number of problems that arise in the Swift compiler:
The [request-evaluator](https://github.com/swiftlang/swift/blob/main/include/swift/AST/Evaluator.h) is a new architectural approach for the Swift compiler that attempts to provide infrastructure for fine-grained tracking and visualization of dependencies, separately caching the results of computation within the compiler, and eliminating mutable state, particular from the Abstract Syntax Tree (AST). It is intended to address a number of problems that arise in the Swift compiler:
* Type checking (as well as later stages) tend to depend on mutable AST state, which is hard to reason about: which mutable state contributed to the result of a type check? How was it computed?
* Type checking, particularly in targets with more source files, is intended to be "lazy": the compiler will try to type check only what is needed to compile the given source file, and nothing more. Combined with mutable state, we often end up with compiler bugs that only manifest in multi-file targets, which are (1) the norm for real-world development, but (2) far less friendly for compiler writers writing test cases.
* Lazy type checking uses an ad hoc set of callbacks captured in the [lazy resolver](https://github.com/apple/swift/blob/main/include/swift/AST/LazyResolver.h). This ad hoc recursion can lead to cycles in the type-checking problem (e.g., to compute A we need to compute B, which depends on A): with mutable state, it's easy to cause either wrong results or infinite recursion.
* Lazy type checking uses an ad hoc set of callbacks captured in the [lazy resolver](https://github.com/swiftlang/swift/blob/main/include/swift/AST/LazyResolver.h). This ad hoc recursion can lead to cycles in the type-checking problem (e.g., to compute A we need to compute B, which depends on A): with mutable state, it's easy to cause either wrong results or infinite recursion.
* Because it's not clear which state is set by a given callback in the `LazyResolver`, the callbacks there tend to be very coarse-grained, e.g., "resolve everything about a declaration that might be used by a client." This performs too much work in multi-file targets (making the compiler slower than it should be) and contributes to more cycles (because coarse-grained queries are more likely to be cyclic where finer-grained ones might not be).
The request-evaluator attempts to address these issues by providing a central
@@ -15,13 +15,13 @@ At the core of the request-evaluator is a "request", which is a query provided t
Each "request" is described by, effectively, a description of a computation to perform. A request is a value type that is capable of comparing/hashing its state, as well as printing its value for debugging purposes. Each request has an evaluation function to compute the result of the request. Only the evaluator itself will invoke the evaluation function, memoizing the result (when appropriate) for subsequent requests.
All existing requests inherit the [`SimpleRequest`](https://github.com/apple/swift/blob/main/include/swift/AST/SimpleRequest.h) class template, which automates most of the boilerplate involved in defining a new request, and mostly abstracts away the handling of the storage/comparison/hashing/printing of the inputs to a request. Some example requests for access control are provided by [`AccessRequests.h`](https://github.com/apple/swift/blob/main/include/swift/AST/AccessRequests.h).
All existing requests inherit the [`SimpleRequest`](https://github.com/swiftlang/swift/blob/main/include/swift/AST/SimpleRequest.h) class template, which automates most of the boilerplate involved in defining a new request, and mostly abstracts away the handling of the storage/comparison/hashing/printing of the inputs to a request. Some example requests for access control are provided by [`AccessRequests.h`](https://github.com/swiftlang/swift/blob/main/include/swift/AST/AccessRequests.h).
## Dependencies and Cycles
Each request can issue other requests, also through the evaluator. The evaluator automatically tracks such dependencies (by keeping a stack of the currently-active request evaluations). This information is valuable for a few reasons. First, it can help with debugging both correctness and performance, allowing one to visualize the dependencies evaluated when compiling a program. The current protocol has both full-graph visualization (via GraphViz output) and dependencies-for-a-single-request visualization (via a tree-like dump). Second, it ensures that we can detect cyclic dependencies (e.g., a cyclic inheritance hierarchy) correctly, because they show up as cycles in the dependency graph, allowing for proper diagnostics (for the user) and recovery (in the compiler). Third, it can eventually be leveraged to enable better incremental compilation--providing the ability to discover what information affected a particular type-checking decision, and propagate the effects of a specific change through the dependency graph.
The frontend option `-debug-cycles` will provide debugging output for any cycle detected while processing the given source files. For example, running the [`circular_inheritance.swift` test](https://github.com/apple/swift/blob/main/test/decl/class/circular_inheritance.swift) from the Swift repository using this flag, e.g.,
The frontend option `-debug-cycles` will provide debugging output for any cycle detected while processing the given source files. For example, running the [`circular_inheritance.swift` test](https://github.com/swiftlang/swift/blob/main/test/decl/class/circular_inheritance.swift) from the Swift repository using this flag, e.g.,
```
$ swiftc -frontend -typecheck -debug-cycles test/decl/class/circular_inheritance.swift
@@ -36,7 +36,7 @@ provides a debugging dump that illustrates the one of the dependency cycles via
`--SuperclassTypeRequest(circular_inheritance.(file).Outer2@test/decl/class/circular_inheritance.swift:38:7) (cyclic dependency)
```
Within the compiler, the core [`Evaluator` class](https://github.com/apple/swift/blob/main/include/swift/AST/Evaluator.h) provides dumping routines such as `dumpDependencies()`, so one can see the dependencies for any request as part of a debugging session. It uses the same textual dump format as `-debug-cycles`.
Within the compiler, the core [`Evaluator` class](https://github.com/swiftlang/swift/blob/main/include/swift/AST/Evaluator.h) provides dumping routines such as `dumpDependencies()`, so one can see the dependencies for any request as part of a debugging session. It uses the same textual dump format as `-debug-cycles`.
The request-evaluator has the ability to emit "real" Swift diagnostics when it encounters a cycle, but they are currently disabled because they fire too often in real-world code. Once enough of the cyclic dependencies in well-formed code have been removed, such that the only errors come from ill-formed code, these diagnostics will be enabled. For example, they will be used to detect ill-formed programs such as:
@@ -72,7 +72,7 @@ The request-evaluator is relatively new to the Swift compiler, having been intro
* Explore how best to cache data structures in the evaluator. For example, caching `std::vector<T>` or `std::string` implies that we'll make copies of the underlying data structure each time we access the data. Could we automatically intern the data into an allocation arena owned by the evaluator, and vend `ArrayRef<T>` and `StringRef` to clients instead?
* Cycle diagnostics are far too complicated and produce very poor results. Consider replacing the current `diagnoseCycle`/`noteCycleStep` scheme with a single method that produces summary information (e.g., a short summary string + source location information) and provides richer diagnostics from that string.
* The `isCached()` check to determine whether a specific instance of a request is worth caching may be at the wrong level, because one generally has to duplicate effort (or worse, code!) to make the decision in `isCached()`. Consider whether the `evaluator()` function could return something special to say "produce this value without caching" vs. the normal "produce this value with caching".
* Try to eliminate more boilerplate from subclasses of [`SimpleRequest`](https://github.com/apple/swift/blob/main/include/swift/AST/SimpleRequest.h). We are going to have a *lot* of requests.
* Try to eliminate more boilerplate from subclasses of [`SimpleRequest`](https://github.com/swiftlang/swift/blob/main/include/swift/AST/SimpleRequest.h). We are going to have a *lot* of requests.
* Each request supports a simple printing operation (via `simple_display`): implement a parsing scheme so we can take the output of `simple_display` and parse it into a request. Build a command-line testing interface so we can parse a source file and make a specific request (e.g., `SuperclassTypeRequest("Foo")`) to see the results.
* Port more mutable-state AST queries over to requests. This often requires a lot of refactoring!
* Port higher-level queries (e.g., those that come from SourceKit) over to the request-evaluator, so we can see the dependencies of a given SourceKit request for testing and performance tuning.

4
docs/SIL.rst
View File

@@ -5652,7 +5652,7 @@ strong reference count is greater than 1.
A discussion of the semantics can be found here:
`is_unique instruction <arcopts_is_unique_>`_
.. _arcopts_is_unique: https://github.com/apple/swift/blob/main/docs/ARCOptimization.md#is_unique-instruction
.. _arcopts_is_unique: https://github.com/swiftlang/swift/blob/main/docs/ARCOptimization.md#is_unique-instruction
begin_cow_mutation
``````````````````
@@ -7023,7 +7023,7 @@ presence or value of the ``enum_extensibility`` Clang attribute.
(See `SE-0192`__ for more information about non-frozen enums.)
__ https://github.com/apple/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md
__ https://github.com/swiftlang/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md
enum
````

2
docs/SILFunctionConventions.md
View File

@@ -80,7 +80,7 @@ Lowered application of the closure has two applied arguments:
The mapping between `SILFunctionType` and `SILFunctionArgument`, which depends
on the SIL stage, is managed by the
[SILFunctionConventions](https://github.com/apple/swift/blob/main/include/swift/SIL/SILFunctionConventions.h)
[SILFunctionConventions](https://github.com/swiftlang/swift/blob/main/include/swift/SIL/SILFunctionConventions.h)
abstraction. This API follows naming conventions to communicate the meaning of the integer indices:
- "Parameters" refer to the function signature's tuple of arguments.

2
docs/SILMemoryAccess.md
View File

@@ -15,7 +15,7 @@ form of access markers. `begin_access` identifies the address of the
formal access and `end_access` delimits the scope of the access. At
the language level, a formal access is an access to a local variable
or class property. For details, see
[SE-0176: Enforce Exclusive Access to Memory](https://github.com/apple/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md)
[SE-0176: Enforce Exclusive Access to Memory](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md)
Access markers are preserved in SIL to:

12
docs/StandardLibraryProgrammersManual.md
View File

@@ -2,9 +2,9 @@
This is meant to be a guide to people working on the standard library. It covers coding standards, code organization, best practices, internal annotations, and provides a guide to standard library internals. This document is inspired by LLVM's excellent [programmer's manual](http://llvm.org/docs/ProgrammersManual.html) and [coding standards](http://llvm.org/docs/CodingStandards.html).
TODO: Should this subsume or link to [StdlibRationales.rst](https://github.com/apple/swift/blob/main/docs/StdlibRationales.rst)?
TODO: Should this subsume or link to [StdlibRationales.rst](https://github.com/swiftlang/swift/blob/main/docs/StdlibRationales.rst)?
TODO: Should this subsume or link to [AccessControlInStdlib.rst](https://github.com/apple/swift/blob/main/docs/AccessControlInStdlib.rst)
TODO: Should this subsume or link to [AccessControlInStdlib.rst](https://github.com/swiftlang/swift/blob/main/docs/AccessControlInStdlib.rst)
In this document, "stdlib" refers to the core standard library (`stdlib/public/core`), our Swift overlays for system frameworks (`stdlib/public/Darwin/*`, `stdlib/public/Windows/*`, etc.), as well as the auxiliary and prototype libraries under `stdlib/private`.
@@ -242,7 +242,7 @@ extension Foo {
#### Core Standard Library
All new public API additions to the core Standard Library must go through the [Swift Evolution Process](https://github.com/apple/swift-evolution/blob/main/process.md). The Core Team must have approved the additions by the time we merge them into the stdlib codebase.
All new public API additions to the core Standard Library must go through the [Swift Evolution Process](https://github.com/swiftlang/swift-evolution/blob/main/process.md). The Core Team must have approved the additions by the time we merge them into the stdlib codebase.
All public APIs should come with documentation comments describing their purpose and behavior. It is highly recommended to use big-oh notation to document any guaranteed performance characteristics. (CPU and/or memory use, number of accesses to some underlying collection, etc.)
@@ -442,7 +442,7 @@ let theBits = unsafeBitCast(&x, ...)
Should only be used if necessary. This has the effect of forcing inlining to occur before any dataflow analyses take place. Unless you specifically need this behavior, use `@_inline(__always)` or some other mechanism. Its primary purpose is to force the compiler's static checks to peer into the body for diagnostic purposes.
Use of this attribute imposes limitations on what can be in the body. For more details, refer to the [documentation](https://github.com/apple/swift/blob/main/docs/TransparentAttr.md).
Use of this attribute imposes limitations on what can be in the body. For more details, refer to the [documentation](https://github.com/swiftlang/swift/blob/main/docs/TransparentAttr.md).
#### `@unsafe_no_objc_tagged_pointer`
@@ -482,7 +482,7 @@ The standard library cannot import the Darwin module (much less an ICU module),
#### `_FixedArray16`
The standard library has an internal array type of fixed size 16. This provides fast random access into contiguous (usually stack-allocated) memory. See [FixedArray.swift](https://github.com/apple/swift/blob/main/stdlib/public/core/FixedArray.swift) for implementation.
The standard library has an internal array type of fixed size 16. This provides fast random access into contiguous (usually stack-allocated) memory. See [FixedArray.swift](https://github.com/swiftlang/swift/blob/main/stdlib/public/core/FixedArray.swift) for implementation.
#### Thread Local Storage
@@ -492,7 +492,7 @@ The standard library utilizes thread local storage (TLS) to cache expensive comp
2. If the member is not trivially initializable, update `_initializeThreadLocalStorage` and `_ThreadLocalStorage.init`.
3. If the field is not trivially destructable, update `_destroyTLS` to properly destroy the value.
See [ThreadLocalStorage.swift](https://github.com/apple/swift/blob/main/stdlib/public/core/ThreadLocalStorage.swift) for more details.
See [ThreadLocalStorage.swift](https://github.com/swiftlang/swift/blob/main/stdlib/public/core/ThreadLocalStorage.swift) for more details.
## Working with Resilience

8
docs/StringManifesto.md
View File

@@ -472,7 +472,7 @@ their naming:
Prefix and suffix operations should be migrated to be subscripting operations
with one-sided ranges i.e. `s.prefix(upTo: i)` should become `s[..<i]`, as
in
[this proposal](https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0132-sequence-end-ops.md).
[this proposal](https://github.com/swiftlang/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0132-sequence-end-ops.md).
With generic subscripting in the language, that will allow us to collapse a wide
variety of methods and subscript overloads into a single implementation, and
give users an easy-to-use and composable way to describe subranges.
@@ -845,7 +845,7 @@ logical operations in different ways, with the following axes:
We should represent these aspects as orthogonal, composable components,
abstracting pattern matchers into a protocol like
[this one](https://github.com/apple/swift/blob/main/test/Prototypes/PatternMatching.swift#L33),
[this one](https://github.com/swiftlang/swift/blob/main/test/Prototypes/PatternMatching.swift#L33),
that can allow us to define logical operations once, without introducing
overloads, and massively reducing API surface area.
@@ -1022,9 +1022,9 @@ domain-specific language (just write ordinary swift code!) and its type safety
problems (put the data right where it belongs!) but the following issues prevent
it from being useful for localized formatting (among other jobs):
* [#44910](https://github.com/apple/swift/issues/44910): We are unable to
* [#44910](https://github.com/swiftlang/swift/issues/44910): We are unable to
restrict types used in string interpolation.
* [#43868](https://github.com/apple/swift/issues/43868): String interpolation
* [#43868](https://github.com/swiftlang/swift/issues/43868): String interpolation
can't distinguish (fragments of) the base string
from the string substitutions.

16
docs/WindowsBuild.md
View File

@@ -45,8 +45,8 @@ From the settings application, go to `Update & Security`. In the `For developer
## Clone the repositories
1. Clone `swift/main` branch of `apple/llvm-project` into the build workspace
2. Clone `apple/swift-cmark`, `apple/swift`, `apple/swift-corelibs-libdispatch`, `apple/swift-corelibs-foundation`, `apple/swift-corelibs-xctest`, `apple/swift-tools-support-core`, `apple/swift-llbuild`, `apple/swift-argument-parser`, `apple/swift-driver`, `swiftlang/swift-package-manager`, `JPSim/Yams`, `swiftlang/indexstore-db` into the build workspace
1. Clone `swift/main` branch of `swiftlang/llvm-project` into the build workspace
2. Clone `swiftlang/swift-cmark`, `swiftlang/swift`, `apple/swift-corelibs-libdispatch`, `apple/swift-corelibs-foundation`, `apple/swift-corelibs-xctest`, `swiftlang/swift-tools-support-core`, `swiftlang/swift-llbuild`, `apple/swift-argument-parser`, `swiftlang/swift-driver`, `swiftlang/swift-package-manager`, `JPSim/Yams`, `swiftlang/indexstore-db` into the build workspace
- Currently, other repositories in the Swift project have not been tested and may not be supported.
@@ -58,16 +58,16 @@ subst S: <path to sources>
```cmd
S:
git clone https://github.com/apple/llvm-project --branch swift/main llvm-project
git clone -c core.autocrlf=input -c core.symlinks=true https://github.com/apple/swift swift
git clone https://github.com/apple/swift-cmark cmark
git clone https://github.com/swiftlang/llvm-project --branch swift/main llvm-project
git clone -c core.autocrlf=input -c core.symlinks=true https://github.com/swiftlang/swift swift
git clone https://github.com/swiftlang/swift-cmark cmark
git clone https://github.com/apple/swift-corelibs-libdispatch swift-corelibs-libdispatch
git clone https://github.com/apple/swift-corelibs-foundation swift-corelibs-foundation
git clone https://github.com/apple/swift-corelibs-xctest swift-corelibs-xctest
git clone https://github.com/apple/swift-tools-support-core swift-tools-support-core
git clone -c core.symlinks=true https://github.com/apple/swift-llbuild swift-llbuild
git clone https://github.com/swiftlang/swift-tools-support-core swift-tools-support-core
git clone -c core.symlinks=true https://github.com/swiftlang/swift-llbuild swift-llbuild
git clone https://github.com/JPSim/Yams Yams
git clone https://github.com/apple/swift-driver swift-driver
git clone https://github.com/swiftlang/swift-driver swift-driver
git clone https://github.com/apple/swift-argument-parser swift-argument-parser
git clone -c core.autocrlf=input https://github.com/swiftlang/swift-package-manager swift-package-manager
git clone https://github.com/swiftlang/indexstore-db indexstore-db

2
docs/archive/TuplesAsArguments.md
View File

@@ -26,6 +26,6 @@ Jordan
P.S. Anyone is allowed to think this is not a worthwhile trade! But part of the purpose of this story is to show that [at the time of SE-0111] we [were] already 90% of the way towards making tuples and function arguments completely separate, even if they have similar syntax. This proposal gets us to maybe 95%.
[SE-0111]: https://github.com/apple/swift-evolution/blob/main/proposals/0111-remove-arg-label-type-significance.md
[SE-0111]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0111-remove-arg-label-type-significance.md
[original message]: https://forums.swift.org/t/review-se-0111-remove-type-system-significance-of-function-argument-labels/3209/41
[Swift 3 naming conventions]: https://swift.org/documentation/api-design-guidelines

30
docs/refactoring/SwiftLocalRefactoring.md
View File

@@ -4,7 +4,7 @@ Xcode 9 includes a brand new refactoring engine. It can transform code locally
within a single Swift source file, or globally, such as renaming a method or property
that occurs in multiple files and even different languages. The logic behind local refactorings is
implemented entirely in the compiler and SourceKit, and is now open source in
the [swift repository](https://github.com/apple/swift). Therefore, any Swift enthusiast can
the [swift repository](https://github.com/swiftlang/swift). Therefore, any Swift enthusiast can
contribute refactoring actions to the language. This post discusses how
a simple refactoring can be implemented and surfaced in Xcode.
@@ -245,7 +245,7 @@ is built alongside the compiler.
Let's again take String Localization as an example. The above code
snippet is a test for contextual refactoring actions.
Similar tests can be found in [test/refactoring/RefactoringKind/](https://github.com/apple/swift/tree/main/test/refactoring/RefactoringKind).
Similar tests can be found in [test/refactoring/RefactoringKind/](https://github.com/swiftlang/swift/tree/main/test/refactoring/RefactoringKind).
Let's take a look at the `RUN` line in more detail, starting with the use of the `%refactor` utility:
@@ -279,7 +279,7 @@ with interpolation.
We should also test that when applying the refactoring, the automated code
change matches our expectations. As a preparation, we need to teach [swift-refactor]
a refactoring kind flag to specify the action we are testing with. To achieve this,
the following entry is added in [swift-refactor.cpp](https://github.com/apple/swift/blob/main/tools/swift-refactor/swift-refactor.cpp):
the following entry is added in [swift-refactor.cpp](https://github.com/swiftlang/swift/blob/main/tools/swift-refactor/swift-refactor.cpp):
~~~cpp
clEnumValN(RefactoringKind::LocalizeString, "localize-string", "Perform String Localization refactoring"),
@@ -321,7 +321,7 @@ After implementing all of above pieces in the Swift codebase, we
are ready to test/use the newly added refactoring in Xcode by integrating with
a locally-built open source toolchain.
1. Run [build-toolchain](https://github.com/apple/swift/blob/main/utils/build-toolchain)
1. Run [build-toolchain](https://github.com/swiftlang/swift/blob/main/utils/build-toolchain)
to build the open source toolchain locally.
2. Untar and copy the toolchain to `/Library/Developer/Toolchains/`.
@@ -334,17 +334,17 @@ following figure illustrates.
## Potential Local Refactoring Ideas
This post just touches on some of the things that are now possible to implement in the new refactoring engine.
If you are excited about extending the refactoring engine to implement additional transformations,
Swift's issue database contains [several ideas of refactoring transformations](https://github.com/apple/swift/issues?q=is%3Aissue+is%3Aopen+label%3ARefactoring) awaiting implementations.
Swift's issue database contains [several ideas of refactoring transformations](https://github.com/swiftlang/swift/issues?q=is%3Aissue+is%3Aopen+label%3ARefactoring) awaiting implementations.
For further help with implementing refactoring transformations, please feel free to ask questions on the [Swift forums](https://forums.swift.org/c/development/compiler/9).
[sourcekitd]: https://github.com/apple/swift/tree/main/tools/SourceKit
[ResolvedCursorInfo]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/Utils.h#L158
[RangeInfo]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/Utils.h#L344
[performChange]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/lib/IDE/Refactoring.cpp#L599
[RefactoringKinds.def]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/RefactoringKinds.def
[isApplicable]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/lib/IDE/Refactoring.cpp#L646
[DiagnosticsRefactoring.def]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/AST/DiagnosticsRefactoring.def
[swift-refactor]: https://github.com/apple/swift/tree/60a91bb7360dde5ce9531889e0ed10a2edbc961a/tools/swift-refactor
[Refactoring.cpp]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/lib/IDE/Refactoring.cpp
[EditConsumer]: https://github.com/apple/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/Utils.h#L506
[sourcekitd]: https://github.com/swiftlang/swift/tree/main/tools/SourceKit
[ResolvedCursorInfo]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/Utils.h#L158
[RangeInfo]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/Utils.h#L344
[performChange]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/lib/IDE/Refactoring.cpp#L599
[RefactoringKinds.def]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/RefactoringKinds.def
[isApplicable]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/lib/IDE/Refactoring.cpp#L646
[DiagnosticsRefactoring.def]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/AST/DiagnosticsRefactoring.def
[swift-refactor]: https://github.com/swiftlang/swift/tree/60a91bb7360dde5ce9531889e0ed10a2edbc961a/tools/swift-refactor
[Refactoring.cpp]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/lib/IDE/Refactoring.cpp
[EditConsumer]: https://github.com/swiftlang/swift/blob/60a91bb7360dde5ce9531889e0ed10a2edbc961a/include/swift/IDE/Utils.h#L506

4
docs/tools/swift.pod
View File

@@ -83,7 +83,7 @@ works, continually evolving to make Swift even better.
Reporting bugs is a great way for anyone to help improve Swift. The issue
tracker for Swift, an open-source project, is located at
L<https://github.com/apple/swift/issues>.
L<https://github.com/swiftlang/swift/issues>.
If a bug can be reproduced only within an Xcode project or a playground, or if
the bug is associated with an Apple NDA, please file a report to Apple's
@@ -101,6 +101,6 @@ L<https://developer.apple.com/swift/resources>
=head2 CODE REPOSITORIES
Swift Programming Language at L<https://github.com/apple/swift>
Swift Programming Language at L<https://github.com/swiftlang/swift>
Swift Package Manager at L<https://github.com/swiftlang/swift-package-manager>