Merge pull request #2229 from hitstergtd/hitstergtd-docfixes-2

[gardening] [docs] Properly capitalise 'swift' to 'Swift'

Author: lattner

Diff for: docs/ARCOptimization.rst

@@ -8,7 +8,7 @@ ARC Optimization for Swift
 
 .. admonition:: TODO
 
-   This is an evolving document on ARC optimization in the swift
+   This is an evolving document on ARC optimization in the Swift
    compiler. Please extend it.
 
 Terms
@@ -332,7 +332,7 @@ is_unique performs depends on the argument type:
       (Builtin.NativeObject, known native class reference)
 
     - Objective-C object types require an additional check that the
-      dynamic object type uses native swift reference counting:
+      dynamic object type uses native Swift reference counting:
       (Builtin.UnknownObject, unknown class reference, class existential)
 
     - Bridged object types allow the dynamic object type check to be
@@ -342,7 +342,7 @@ is_unique performs depends on the argument type:
 Any of the above types may also be wrapped in an optional.  If the
 static argument type is optional, then a null check is also performed.
 
-Thus, is_unique only returns true for non-null, native swift object
+Thus, is_unique only returns true for non-null, native Swift object
 references with a strong reference count of one.
 
 is_unique_or_pinned has the same semantics as is_unique except that it

Diff for: docs/DebuggingTheCompiler.rst

@@ -9,13 +9,13 @@ Abstract
 --------
 
 This document contains some useful information for debugging the
-swift compiler and swift compiler output.
+Swift compiler and Swift compiler output.
 
 Printing the Intermediate Representations
 -----------------------------------------
 
 The most important thing when debugging the compiler is to examine the IR.
-Here is how to dump the IR after the main phases of the swift compiler
+Here is how to dump the IR after the main phases of the Swift compiler
 (assuming you are compiling with optimizations enabled):
 
 #. **Parser**. To print the AST after parsing::
@@ -83,7 +83,7 @@ For details see ``PassManager.cpp``.
 Dumping the SIL and other Data in LLDB
 ``````````````````````````````````````
 
-When debugging the swift compiler with LLDB (or Xcode, of course), there is
+When debugging the Swift compiler with LLDB (or Xcode, of course), there is
 even a more powerful way to examine the data in the compiler, e.g. the SIL.
 Following LLVM's dump() convention, many SIL classes (as well as AST classes)
 provide a dump() function. You can call the dump function with LLDB's
@@ -123,7 +123,7 @@ debugging add the front-end option -gsil together with -g. Example::
 
 This writes the SIL after optimizations into a file and generates debug info
 for it. In the debugger and profiler you can then see the SIL code instead of
-the swift source code.
+the Swift source code.
 For details see the SILDebugInfoGenerator pass.
 
 To enable SIL debugging and profiling for the Swift standard library, use
@@ -141,7 +141,7 @@ Using Breakpoints
 `````````````````
 
 LLDB has very powerful breakpoints, which can be utilized in many ways to debug
-the compiler and swift executables. The examples in this section show the LLDB
+the compiler and Swift executables. The examples in this section show the LLDB
 command lines. In Xcode you can set the breakpoint properties by clicking 'Edit
 breakpoint'.
 
@@ -236,7 +236,7 @@ generality will be called test.lldb)::
     c
     dis -f
 
-TODO: Change this example to apply to the swift compiler instead of to the
+TODO: Change this example to apply to the Swift compiler instead of to the
 stdlib unittests.
 
 Then by running ``lldb test -s test.lldb``, lldb will:
@@ -256,14 +256,14 @@ needing to retype the various commands perfectly every time.
 Debugging Swift Executables
 ---------------------------
 
-One can use the previous tips for debugging the swift compiler with swift
+One can use the previous tips for debugging the Swift compiler with Swift
 executables as well. Here are some additional useful techniques that one can use
 in Swift executables.
 
 Determining the mangled name of a function in LLDB
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-One problem that often comes up when debugging swift code in LLDB is that LLDB
+One problem that often comes up when debugging Swift code in LLDB is that LLDB
 shows the demangled name instead of the mangled name. This can lead to mistakes
 where due to the length of the mangled names one will look at the wrong
 function. Using the following command, one can find the mangled name of the

Diff for: docs/Generics.rst

@@ -204,7 +204,7 @@ interface, e.g. (in Java)::
 
 .. @ignore()
 .. This test just doesn't compile at the moment, but that represents a
-   bug in swift
+   bug in Swift
 
 and then a class X that wants to be Comparable will inherit from
 Comparable<X>. This is ugly and has a number of pitfalls; see

Diff for: docs/HighLevelSILOptimizations.rst

@@ -96,7 +96,7 @@ getElement instruction::
 
 Swift optimizations
 -------------------
-The swift optimizer can access the information that is provided by the
+The Swift optimizer can access the information that is provided by the
 ``@_semantics`` attribute to perform high-level optimizations. In the early
 stages of the optimization pipeline the optimizer does not inline functions
 with special semantics in order to allow the early high-level optimization

Diff for: docs/OptimizationTips.rst

@@ -386,7 +386,7 @@ about 10 times.
 
   Game(10).play
 
-The cost of large swift values
+The cost of large Swift values
 ==============================
 
 In Swift, values keep a unique copy of their data. There are several advantages
@@ -501,12 +501,12 @@ The type ``Box`` can replace the array in the code sample above.
 Unsafe code
 ===========
 
-Swift classes are always reference counted. The swift compiler inserts code
+Swift classes are always reference counted. The Swift compiler inserts code
 that increments the reference count every time the object is accessed.
 For example, consider the problem of scanning a linked list that's
 implemented using classes. Scanning the list is done by moving a
 reference from one node to the next: ``elem = elem.next``. Every time we move
-the reference swift will increment the reference count of the ``next`` object
+the reference Swift will increment the reference count of the ``next`` object
 and decrement the reference count of the previous object. These reference
 count operations are expensive and unavoidable when using Swift classes.
 

Diff for: docs/SIL.rst

@@ -115,7 +115,7 @@ IR.
 - **Performance Inlining**
 - **Reference Counting Optimizations**
 - **Memory Promotion/Optimizations**
-- **High-level domain specific optimizations** The swift compiler implements
+- **High-level domain specific optimizations** The Swift compiler implements
   high-level optimizations on basic Swift containers such as Array or String.
   Domain specific optimizations require a defined interface between
   the standard library and the optimizer. More details can be found here:

Diff for: docs/StringDesign.rst

@@ -151,7 +151,7 @@ __ https://en.wikipedia.org/wiki/First-class_citizen
   |swift| var s = "Yo"
   `// s:` :emph:`String` `= "Yo"`
 
-Unlike, say, C's ``char*``, the meaning of a swift string is always
+Unlike, say, C's ``char*``, the meaning of a Swift string is always
 unambiguous.
 
 Strings are **Efficient**