diff --git a/docs/ABI/GenericSignature.md b/docs/ABI/GenericSignature.md index 0eb2f77a20190..19c688b8de9f4 100644 --- a/docs/ABI/GenericSignature.md +++ b/docs/ABI/GenericSignature.md @@ -41,14 +41,14 @@ Consider the following generic signature: The constraint `C1.Element: Equatable` is redundant (because it can be proven based on `C1.Element == C2.Element` and `C2.Element: Equatable`). Similarly, `C2.Element: Equatable` is redundant (based on `C1.Element == C2.Element` and `C1.Element: Equatable`). Either one of these constraints can be removed without changing the semantics of the generic signature, and the resulting generic signature will be minimal (there are no redundant constraints that remain). As such, there are two minimal generic signatures that describe this set of constraints: ```swift - ``` and ```swift - ``` @@ -60,19 +60,19 @@ A generic signature is *canonical* when each of its constraints is [canonical](# 1. Generic type parameters are listed first ordered by [type parameter ordering](#type-parameter-ordering) -2. Constraints follow, ordered first by the - [type parameter ordering](#type-parameter-ordering) of the left-hand +2. Constraints follow, ordered first by the + [type parameter ordering](#type-parameter-ordering) of the left-hand operand and then by constraint kind. The left-hand side of a constraint is always a type parameter (call it `T`). Constraints are ordered as follows: 1. A superclass constraint `T: C`, where `C` is a class. 2. A layout constraint (e.g., `T: some-layout`), where the right-hand - side is `AnyObject` or one of the non-user-visible layout constraints + side is `AnyObject` or one of the non-user-visible layout constraints like `_Trivial`. - 3. Conformance constraints `T: P`, where `P` is a protocol. The - conformance constraints for a given type parameter `T` are further + 3. Conformance constraints `T: P`, where `P` is a protocol. The + conformance constraints for a given type parameter `T` are further sorted using the [protocol ordering](#protocol-ordering). - 4. A same-type constraint `T == U`, where `U` is either a type parameter + 4. A same-type constraint `T == U`, where `U` is either a type parameter or a concrete type. ### Type parameter ordering @@ -117,7 +117,7 @@ Each equivalence class has a corresponding *anchor*, which is a type parameter t A layout or conformance constraint is canonical when its left-hand side is the anchor of its equivalence class. A superclass constraint is canonical when its left-hand side is the anchor of its equivalence class and its right-hand side is a canonical concrete (class) type. Same-type constraint canonicalization is discussed in detail in the following section, but some basic rules apply: the left-hand side is always a type parameter, and the right-hand side is either a type parameter that follows the left-hand side (according to the [type parameter ordering](#type-parameter-ordering)) or is a canonical concrete type. -### Same-type constaints +### Same-type constraints The canonical form of superclass, layout, and conformance constraints are directly canonicalizable once the equivalence classes are known. Same-type constraints, on the other hand, are responsible for forming those equivalence classes. Let's expand our running example to include a third `Collection`: @@ -138,13 +138,13 @@ or C1.Element == C2.Element, C2.Element == C3.Element ``` -or +or ```swift C1.Element == C3.Element, C2.Element == C3.Element ``` -All of these sets of constraints have the same effect (i.e., form the same equivalence class), but the second one happens to be the canonical form. +All of these sets of constraints have the same effect (i.e., form the same equivalence class), but the second one happens to be the canonical form. The canonical form is determined by first dividing all of the types in the same equivalence class into distinct components. Two types `T1` and `T2` are in the same component if the same type constraint `T1 == T2` can be proven true based on other known constraints in the generic signature (i.e., if `T1 == T2` would be redundant). For example, `C1.Element` and `C1.SubSequence.Elemenent` are in the same component, because `C1: Collection` and the `Collection` protocol contains the constraint `Element == SubSequence.Element`. However, `C1.Element` and `C2.Element` are in different components. @@ -162,7 +162,7 @@ For the first case, consider a function that operates on `String` collections: ```swift func manyStrings( c1: C1, c2: C2, c3: C3) - where C1.Element == String, C1.Element == C2.Element, + where C1.Element == String, C1.Element == C2.Element, C1.Element == C3.SubSequence.Element { } ``` @@ -170,7 +170,7 @@ func manyStrings( The minimal canonical generic signature for this function is: ```swift - ``` @@ -189,4 +189,3 @@ protocol Collection: Sequence where SubSequence: Collection { ``` This protocol introduces a number of constraints: `Self: Sequence` (stated as inheritance), `Self.SubSequence: Collection` (in the protocol where clause), `Self.Indices: Collection` (associated type declaration) and `Self.Indices.Element == Index` (associated type where clause). These constraints, which are directly implied by `Self: Collection`, form the *requirement signature* of a protocol. As with other generic signatures used for the ABI, the requirement signature is minimal and canonical according to the rules described elsewhere in this document. - diff --git a/docs/ABI/KeyPaths.md b/docs/ABI/KeyPaths.md index 3f81a091d9ada..f07b6ad1e0909 100644 --- a/docs/ABI/KeyPaths.md +++ b/docs/ABI/KeyPaths.md @@ -10,7 +10,7 @@ way that it can be transformed in-place into a key path object with a one-time initialization in the common case where the entire path is fully specialized and crosses no resilience boundaries. -## ABI Concerns For Key Paths +## ABI Concerns For Key Paths For completeness, this document describes the layout of both key path objects and patterns; note however that the instantiated runtime layout of key path @@ -18,7 +18,7 @@ objects is an implementation detail of the Swift runtime, and *only key path patterns* are strictly ABI, since they are emitted by the compiler. The runtime has the freedom to change the runtime layout of key path objects, but will have to maintain the ability to instantiate from key path patterns emitted -by previous ABI-stable versions of the Swift complier. +by previous ABI-stable versions of the Swift compiler. ## Key Path Objects @@ -202,10 +202,10 @@ Value in bit 30&29 | Description `2*sizeof(Int)` | **Is Equal** `3*sizeof(Int)` | **Hash** - The *destroy* function, if not null, has signature + The *destroy* function, if not null, has signature `@convention(thin) (UnsafeMutableRawPointer) -> ()` and is invoked to destroy the captures when the key path object is deallocated. - + The *copy* function has signature `@convention(thin) (_ src: UnsafeRawPointer, _ dest: UnsafeMutableRawPointer) -> ()` diff --git a/docs/DebuggingTheCompiler.rst b/docs/DebuggingTheCompiler.rst index 4930dec45d6fb..eb155f00aded4 100644 --- a/docs/DebuggingTheCompiler.rst +++ b/docs/DebuggingTheCompiler.rst @@ -257,7 +257,7 @@ There is another useful script to view the CFG of a disassembled function: It splits a disassembled function up into basic blocks which can then be used with viewcfg:: - (lldb) disassemble + (lldb) disassemble $ blockifyasm < file.s | viewcfg @@ -458,7 +458,7 @@ That will write the types log to the file passed to the -f option. **NOTE** Module loading can happen as a side-effect of other operations in lldb (e.g. the "file" command). To be sure that one has enabled logging before /any/ - module loading has occured, place the command into either:: + module loading has occurred, place the command into either:: ~/.lldbinit $PWD/.lldbinit @@ -483,8 +483,8 @@ following non-exhaustive list of state: 1. The unparsed, textual expression passed to the compiler. 2. The parsed expression. 3. The initial SILGen. -4. SILGen after SILLinking has occured. -5. SILGen after SILLinking and Guaranteed Optimizations have occured. +4. SILGen after SILLinking has occurred. +5. SILGen after SILLinking and Guaranteed Optimizations have occurred. 6. The resulting LLVM IR. 7. The assembly code that will be used by the JIT. diff --git a/docs/Generics.rst b/docs/Generics.rst index 225bd041be8d7..47bcfa64961d5 100644 --- a/docs/Generics.rst +++ b/docs/Generics.rst @@ -747,7 +747,7 @@ The exact syntax of the @_specialize function attribute is defined as: :: @_specialize(exported: false, kind: partial, where K: _Trivial64) func dictFunction(dict: Dictionary) { } - + If 'exported' is set, the corresponding specialization would have a public visibility and can be used by clients. If 'exported' is omitted, it's value is assumed to be 'false'. @@ -757,7 +757,7 @@ produce an error if you forget to specify the type for some of the generic parameters in the 'where' clause. If 'kind' is 'partial' it means a partial specialization. If 'kind' is omitted, its value is assumed to be 'full. -The requirements in the where clause may be same-type constaints like 'T == Int', +The requirements in the where clause may be same-type constraints like 'T == Int', but they may also specify so-called layout constraints like 'T: _Trivial'. The following layout constraints are currently supported: @@ -773,7 +773,7 @@ The following layout constraints are currently supported: exactly 'SizeInBits' bits. * _TrivialAtMost(SizeInBits) - like _Trivial, but the size of the type should be at most 'SizeInBits' bits. - + Existential Types and Generics ------------------------------ diff --git a/docs/SIL.rst b/docs/SIL.rst index 4dba04677cc12..0020951a497e6 100644 --- a/docs/SIL.rst +++ b/docs/SIL.rst @@ -3188,7 +3188,7 @@ executing the ``begin_apply``) were being "called" by the ``yield``: - The convention attributes are the same as the parameter convention attributes, interpreted as if the ``yield`` were the "call" and the ``begin_apply`` marked the entry to the "callee". For example, - an ``@in Any`` yield transferrs ownership of the ``Any`` value + an ``@in Any`` yield transfers ownership of the ``Any`` value reference from the coroutine to the caller, which must destroy or move the value from that position before ending or aborting the coroutine. @@ -3714,7 +3714,7 @@ destructure_struct // %0 must be a struct of type $S // %eltN must have the same type as the Nth field of $S -Given a struct, split the struct into its constituant fields. +Given a struct, split the struct into its constituent fields. object `````` @@ -3729,7 +3729,7 @@ object Constructs a statically initialized object. This instruction can only appear as final instruction in a global variable static initializer list. - + ref_element_addr ```````````````` :: @@ -4026,7 +4026,7 @@ container may use one of several representations: Said value might be replaced with one of the _addr instructions above before IR generation. The following instructions manipulate "loadable" opaque existential containers: - + * `init_existential_value`_ * `open_existential_value`_ * `deinit_existential_value`_ diff --git a/docs/StandardLibraryProgrammersManual.md b/docs/StandardLibraryProgrammersManual.md index e9d0dd1c37c65..12628f440031d 100644 --- a/docs/StandardLibraryProgrammersManual.md +++ b/docs/StandardLibraryProgrammersManual.md @@ -12,7 +12,7 @@ TODO: Should this subsume or link to [AccessControlInStdlib.rst](https://github. 1. Library Organization 1. What files are where 1. Brief about CMakeLists - 1. Brief about GroupInfo.json + 1. Brief about GroupInfo.json 1. What tests are where 1. Furthermore, should there be a split between whitebox tests and blackbox tests? 1. What benchmarks are where @@ -23,7 +23,7 @@ TODO: Should this subsume or link to [AccessControlInStdlib.rst](https://github. 1. Protocol hierarchy 1. Customization hooks 1. Use of classes, COW implementation, buffers, etc - 1. Compatiblity, `@available`, etc. + 1. Compatibility, `@available`, etc. 1. Resilience, ABI stability, `@_inlineable`, `@_versioned`, etc 1. Strings and ICU 1. Lifetimes @@ -75,8 +75,8 @@ if _fastPath(...) { ... if _fastPath(...) { // 9% of the time we execute this: very conservative inlining - ... - return + ... + return } // 1% of the time we execute this: very conservative inlining @@ -87,7 +87,7 @@ return *NOTE: these are due for a rename and possibly a redesign. They conflate multiple notions that don’t match the average standard library programmer’s intuition.* -#### `_onFastPath` +#### `_onFastPath` This should be rarely used. It informs the SIL optimizer that any code dominated by it should be treated as the innermost loop of a performance critical section of code. It cranks optimizer heuristics to 11. Injudicious use of this will degrade performance and bloat binary size. @@ -170,5 +170,3 @@ The standard library utilizes thread local storage (TLS) to cache expensive comp 3. If the field is not trivially destructable, update `_destroyTLS` to properly destroy the value. See [ThreadLocalStorage.swift](https://github.com/apple/swift/blob/master/stdlib/public/core/ThreadLocalStorage.swift) for more details. - - diff --git a/docs/refactoring/SwiftLocalRefactoring.md b/docs/refactoring/SwiftLocalRefactoring.md index d046159a80238..e19dcf0435031 100644 --- a/docs/refactoring/SwiftLocalRefactoring.md +++ b/docs/refactoring/SwiftLocalRefactoring.md @@ -162,7 +162,7 @@ Though a little more complex than its counterpart in the aforementioned String Localization refactoring, this implementation is self-explaining too. Lines 3 to 4 check the kind of the given range, which has to be a single expression to proceed with the extraction. Lines 5 to 7 ensure the extracted expression has -a well-formed type. Further conditions that need to be checked are ommitted in +a well-formed type. Further conditions that need to be checked are omitted in the example for now. Interested readers can refer to [Refactoring.cpp] for more details. For the code change part, we can use the same [RangeInfo] instance to emit textual edits: