From 5eaa3c43d069d5bd401e7879b43f6290823d180d Mon Sep 17 00:00:00 2001 From: Stefan Natchev Date: Thu, 3 Dec 2015 21:33:17 -0500 Subject: [PATCH] Fix typos in documentation --- docs/ErrorHandlingRationale.rst | 4 ++-- docs/HighLevelSILOptimizations.rst | 4 ++-- docs/Pattern Matching.rst | 2 +- docs/StdlibRationales.rst | 2 +- docs/archive/Objective-C Interoperability.rst | 2 +- docs/doxygen.cfg.in | 4 ++-- docs/proposals/Accessors.rst | 2 +- docs/proposals/ArrayBridge.rst | 2 +- docs/proposals/AttrC.rst | 4 ++-- docs/proposals/Concurrency.rst | 2 +- docs/proposals/DeclarationTypeChecker.rst | 2 +- docs/proposals/InoutCOWOptimization.rst | 2 +- docs/proposals/ObjC Interoperation.rst | 2 +- 13 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/ErrorHandlingRationale.rst b/docs/ErrorHandlingRationale.rst index 8714409f5f33b..a6496801d6733 100644 --- a/docs/ErrorHandlingRationale.rst +++ b/docs/ErrorHandlingRationale.rst @@ -173,7 +173,7 @@ be quite amazing for us to assert that code shouldn't be written that way, understanding nothing else about it. As long as programmers do face these issues, the language has some responsibility to help them. -Therefore, in my judgement, promoting the use of universal errors is +Therefore, in my judgment, promoting the use of universal errors is highly problematic. They undermine the easy comprehension of code, and they undermine the language's ability to help the programmer reason about errors. This design will instead focus on explicitly @@ -577,7 +577,7 @@ they produce, and so many errors just end up falling into broad buckets. Different libraries end up with their own library-specific general error classes, and exceptions list end up just restating the library's own dependencies or wrapping the underlying errors in ways -that loses criticial information. +that loses critical information. Tradeoffs of typed propagation diff --git a/docs/HighLevelSILOptimizations.rst b/docs/HighLevelSILOptimizations.rst index 35ca6e4b53d0e..fa2132859593d 100644 --- a/docs/HighLevelSILOptimizations.rst +++ b/docs/HighLevelSILOptimizations.rst @@ -335,13 +335,13 @@ readwrite Optimize semantics attribute ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The optimize attribute adds function-sepcific directives to the optimizer. +The optimize attribute adds function-specific directives to the optimizer. The optimize attribute supports the following tags: sil.never - The sil optimizer should not optimize this funciton. + The sil optimizer should not optimize this function. Example: @_semantics("optimize.sil.never") diff --git a/docs/Pattern Matching.rst b/docs/Pattern Matching.rst index b3794de132a20..d0bfedd6c2dfd 100644 --- a/docs/Pattern Matching.rst +++ b/docs/Pattern Matching.rst @@ -26,7 +26,7 @@ Swift has a pretty small set of types right now: * Function types. * Tuples. Heterogeneous fixed-length products. Swift's system provides two basic kinds of element: positional and labelled. -* Arrays. Homogenous fixed-length aggregates. +* Arrays. Homogeneous fixed-length aggregates. * Algebraic data types (ADTs), introduce by enum. Nominal closed disjoint unions of heterogeneous types. * Struct types. Nominal heterogeneous fixed-length products. diff --git a/docs/StdlibRationales.rst b/docs/StdlibRationales.rst index 8669653885f91..02d423d4b0a6d 100644 --- a/docs/StdlibRationales.rst +++ b/docs/StdlibRationales.rst @@ -159,7 +159,7 @@ functions don't return lazy collection wrappers that refer to users' closures. The consequence is that all users' closures are ``@noescape``, except in an explicitly lazy context. -Based on this rule, we conclude that ``enumeraate()``, ``zip()`` and +Based on this rule, we conclude that ``enumerate(), ``zip()`` and ``reverse()`` return lazy wrappers, but ``filter()`` and ``map()`` don't. For the first three functions being lazy is the right default, since usually the result is immediately consumed by for-in, so we don't want to allocate memory diff --git a/docs/archive/Objective-C Interoperability.rst b/docs/archive/Objective-C Interoperability.rst index c8921e0107a43..5524eb4cfa71b 100644 --- a/docs/archive/Objective-C Interoperability.rst +++ b/docs/archive/Objective-C Interoperability.rst @@ -320,7 +320,7 @@ Methods marked as "overrideable API" only have Objective-C entry points: - Less to think about, maximum compatibility. - Penalizes future Swift clients (and potentially Objective-C clients?). -Methods marked as "overrideable API" have both Objective-C and Swift entry +Methods marked as "overridable API" have both Objective-C and Swift entry points: - Requires teaching Clang to emit Swift vtables. diff --git a/docs/doxygen.cfg.in b/docs/doxygen.cfg.in index 5468e2386843e..959357b827959 100644 --- a/docs/doxygen.cfg.in +++ b/docs/doxygen.cfg.in @@ -385,7 +385,7 @@ SHOW_DIRECTORIES = YES # version control system). Doxygen will invoke the program by executing (via # popen()) the command , where is the value of # the FILE_VERSION_FILTER tag, and is the name of an input file -# provided by doxygen. Whatever the progam writes to standard output +# provided by doxygen. Whatever the program writes to standard output # is used as the file version. See the manual for examples. #FILE_VERSION_FILTER = @@ -418,7 +418,7 @@ WARN_IF_UNDOCUMENTED = NO WARN_IF_DOC_ERROR = YES -# This WARN_NO_PARAMDOC option can be abled to get warnings for +# This WARN_NO_PARAMDOC option can be enabled to get warnings for # functions that are documented, but have no documentation for their parameters # or return value. If set to NO (the default) doxygen will only warn about # wrong or incomplete parameter documentation, but not about the absence of diff --git a/docs/proposals/Accessors.rst b/docs/proposals/Accessors.rst index 2af6d07517a36..e4f0f19b82f93 100644 --- a/docs/proposals/Accessors.rst +++ b/docs/proposals/Accessors.rst @@ -1296,7 +1296,7 @@ Code generation patterns The signatures and access patterns for addressors will need to change in order to ensure memory-safety. -``mutableAddress`` currentlys returns an ``UnsafeMutablePointer``; it +``mutableAddress`` currently returns an ``UnsafeMutablePointer``; it will need to return ``(Builtin.NativeObject?, UnsafeMutablePointer)``. The owner pointer must be a native object; we cannot efficiently support either uniqueness checking or the NSM bit on non-Swift diff --git a/docs/proposals/ArrayBridge.rst b/docs/proposals/ArrayBridge.rst index 163fb487874f7..a3bc33009952c 100644 --- a/docs/proposals/ArrayBridge.rst +++ b/docs/proposals/ArrayBridge.rst @@ -71,7 +71,7 @@ significant. For example, the design above would pose significant performance problems for arrays of integers, because every subscript operation would have to check to see if the representation is an NSArray, realize it is not, then do the constant time index into the native representation. Beyond requiring an extra -check, this check would disable optimizations that can provide a signficant +check, this check would disable optimizations that can provide a significant performance win (like auto-vectorization). However, the inherent limitations of ``NSArray`` mean that we can diff --git a/docs/proposals/AttrC.rst b/docs/proposals/AttrC.rst index 2c4d2cf193b88..e633857eee7b3 100644 --- a/docs/proposals/AttrC.rst +++ b/docs/proposals/AttrC.rst @@ -4,7 +4,7 @@ Eventually, we would like to write Swift modules which define pure-C entry points for top-level functions, and be able to export more data types to C code. -This will be imporant for the Linux port, but also perhaps for system +This will be important for the Linux port, but also perhaps for system frameworks that want to transition to Swift. The radars tracking this work are: @@ -59,7 +59,7 @@ and "non-POD". POD types include: On Linux, we can't have reference counted pointers here at all, and NSArray, etc do not exist, so only POD types are bridgeable. We must -ensure that we produce ther right diagnostic and not crash when the +ensure that we produce the right diagnostic and not crash when the user references NSArray, etc on Linux. On Darwin, we can allow passing reference counted pointers directly diff --git a/docs/proposals/Concurrency.rst b/docs/proposals/Concurrency.rst index f74ca909f2664..995bd532ee8fc 100644 --- a/docs/proposals/Concurrency.rst +++ b/docs/proposals/Concurrency.rst @@ -629,7 +629,7 @@ use actors can scale to support millions of concurrent actors because actors are not backed by a live thread or by a stack. In Swift actors could be implemented using classes that inherit from the generic -``Actor`` class. The generic parameter determins the type of messages that the +``Actor`` class. The generic parameter determines the type of messages that the actor can accept. The message type needs to be of ``CopyableType`` to ensure the safety of the model. The actor class exposes two methods: ``send`` and ``accept``. Messages are sent to actors using the ``send`` method and they never diff --git a/docs/proposals/DeclarationTypeChecker.rst b/docs/proposals/DeclarationTypeChecker.rst index bf49ac51d1c74..6195f87e438c4 100644 --- a/docs/proposals/DeclarationTypeChecker.rst +++ b/docs/proposals/DeclarationTypeChecker.rst @@ -176,7 +176,7 @@ How do we measure progress? The proposed change is a major architectural shift, and it's only complete when we have eliminated all ad hoc recursion from the front end. There are a few ways in which we can measure progress along the way: -**AST nodes that implement the phase-aware trait**: Eventually, all of our AST nodes will implement the phase-aware trait. The number of AST nodes that do properly implement that trait (reporting current phase, enumerating dependencies for a phase transition) and become part of the dependency graph and priorty queue gives an indication of how far we've gotten. +**AST nodes that implement the phase-aware trait**: Eventually, all of our AST nodes will implement the phase-aware trait. The number of AST nodes that do properly implement that trait (reporting current phase, enumerating dependencies for a phase transition) and become part of the dependency graph and priority queue gives an indication of how far we've gotten. **Accessors that check the current phase**: When we're finished, each of the AST's accessors should assert that the AST node is in the appropriate phase. The number of such assertions that have been enabled is an indication of how well the type checker is respecting the dependencies. diff --git a/docs/proposals/InoutCOWOptimization.rst b/docs/proposals/InoutCOWOptimization.rst index 4f0543fcbf2ed..cc88b59e77ffc 100644 --- a/docs/proposals/InoutCOWOptimization.rst +++ b/docs/proposals/InoutCOWOptimization.rst @@ -7,7 +7,7 @@ :Authors: Dave Abrahams, Joe Groff :Summary: Our writeback model interacts with Copy-On-Write (COW) to - cause some surprising ineffiencies, such as O(N) performance + cause some surprising inefficiencies, such as O(N) performance for ``x[0][0] = 1``. We propose a modified COW optimization that recovers O(1) performance for these cases and supports the efficient use of slices in algorithm implementation. diff --git a/docs/proposals/ObjC Interoperation.rst b/docs/proposals/ObjC Interoperation.rst index 90c142680b924..2eb2586c4b591 100644 --- a/docs/proposals/ObjC Interoperation.rst +++ b/docs/proposals/ObjC Interoperation.rst @@ -330,7 +330,7 @@ difference between a stored property and its underlying storage, For another example, code class might access -In bot hcaess, t makes sense to organize the code that way, +In both cases, t makes sense to organize the code that way, but Objective C punishes the performance of that code in order to reserve the language's