Merge pull request #2116 from practicalswift/gardening-20160409

[gardening] Fix typos.

Author: practicalswift

CHANGELOG.md

@@ -2722,7 +2722,7 @@ Swift 2.2
 
   In many common cases, this will just work.  Unfortunately, values
   are returned from `CF`-style APIs in a wide variety of ways, and
-  unlike Objective C methods, there simply isn't enough consistency
+  unlike Objective-C methods, there simply isn't enough consistency
   for Swift to be able to safely apply the documented conventions
   universally.  The framework teams have already audited many of the
   most important `CF`-style APIs, and those APIs should be imported

apinotes/CoreGraphics.apinotes

@@ -224,9 +224,9 @@ Functions:
 - Name: CGContextSetAllowsFontSubpixelQuantization
   SwiftName: CGContextRef.setAllowsFontSubpixelQuantization(self:_:)
 - Name: CGContextBeginTransparencyLayer
-  SwiftName: CGContextRef.beginTransparencyLayer(self:withAuxilaryInfo:)
+  SwiftName: CGContextRef.beginTransparencyLayer(self:withAuxiliaryInfo:)
 - Name: CGContextBeginTransparencyLayerWithRect
-  SwiftName: CGContextRef.beginTransparencyLayer(self:in:auxilaryInfo:)
+  SwiftName: CGContextRef.beginTransparencyLayer(self:in:auxiliaryInfo:)
 # CGEvent
 - Name: CGEventCreateFromData
   SwiftName: CGEventRef.init(withDataAllocator:data:)

docs/proposals/ObjCInteroperation.rst

@@ -7,12 +7,12 @@
 :Authors: John McCall
 
 I propose some elementary semantics and limitations when exposing
-Swift code to Objective C and vice-versa.
+Swift code to Objective-C and vice-versa.
 
 Dynamism in Objective-C
 =======================
 
-Objective C intentionally defines its semantics almost entirely around
+Objective-C intentionally defines its semantics almost entirely around
 its implementation model.  The implementation supports two basic
 operations that you can perform on any object:
 
@@ -142,13 +142,13 @@ Method devirtualization [2]_ is likely to be a critically important
 optimization in Swift.
 
 .. [2] In contrast to generic or existential devirtualization, which
-       are also important, but which aren't affected by the Objective C
+       are also important, but which aren't affected by the Objective-C
        interoperation model.
 
 A Missing Optimization
 ----------------------
 
-For one, it is an important missing optimization even in Objective C.
+For one, it is an important missing optimization even in Objective-C.
 Any program that tries to separate its concerns will usually introduce
 some extra abstraction in its formal model.  For example:
 
@@ -165,15 +165,15 @@ some extra abstraction in its formal model.  For example:
 
 In each of the examples, the user has made a totally reasonable
 decision about code organization and reserved flexibility, and
-Objective C proceeds to introduce unnecessary runtime costs which
+Objective-C proceeds to introduce unnecessary runtime costs which
 might force a performance-sensitive programmer to choose a different
 path.
 
 Swift-Specific Concerns
 -----------------------
 
 The lack of devirtualization would hit Swift much harder because of
-its property model.  With a synthesized property, Objective C provides
+its property model.  With a synthesized property, Objective-C provides
 a way to either call the getter/setter (with dot syntax) or directly
 access the underlying ivar (with arrow syntax).  By design, Swift
 hides that difference, and the abstract language model is that all
@@ -195,9 +195,9 @@ for now) and determine whether we can access the property directly.
 But for properties of a class type, polymorphism requires us to
 defensively handle the possibility that a subclass might add arbitrary
 logic to either the getter or setter.  If our implementation model
-is as unrestricted as Objective C's, that's a serious problem.
+is as unrestricted as Objective-C's, that's a serious problem.
 
-I think that this is such a massive regression from Objective C that
+I think that this is such a massive regression from Objective-C that
 we have to address it.
 
 Requirements for Devirtualization
@@ -211,13 +211,13 @@ add and replace method implementations.
 Restricting Method Replacement
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-There are two supported ways to add or replace methods in Objective C.
+There are two supported ways to add or replace methods in Objective-C.
 
 The first is via the runtime API.  If we do have to support doing this
 to replace Swift methods --- and we should try to avoid that --- then
 I think restricting it to require a ``@dynamic`` annotation on the
 replaceable method (or its lexical context) is reasonable.  We should
-try to get the Objective C runtime to complain about attempts to
+try to get the Objective-C runtime to complain about attempts to
 replace non-dynamic methods.
 
 The second is via categories.  It's generally understood that a
@@ -289,7 +289,7 @@ We can reason forward from the point of allocation.
 Access Control
 --------------
 
-Swift does give us one big tool for devirtualization that Objective C
+Swift does give us one big tool for devirtualization that Objective-C
 lacks: access control.  In Swift, access control determines
 visibility, and it doesn't make sense to override something that you
 can't see.  Therefore:
@@ -309,13 +309,13 @@ can't see.  Therefore:
 This means that a private stored property can always be
 "devirtualized" into a direct access [4]_.  Unfortunately, ``private``
 is not the default access control: module-private is.  And if the
-current module can contain Objective C code, then even that raises the
+current module can contain Objective-C code, then even that raises the
 question of what ObjC interop actually means.
 
 .. [4] Assuming we don't introduce a supported way of dynamically
        replacing the implementation of a private Swift method!
 
-Using Swift Classes from Objective C
+Using Swift Classes from Objective-C
 ====================================
 
 
@@ -331,7 +331,7 @@ For another example, code
 class might access 
 
 In both cases, t makes sense to organize the code that way,
-but Objective C punishes the performance of that code in order to
+but Objective-C punishes the performance of that code in order to
 reserve the language's 
 
 

docs/proposals/rejected/ClassConstruction.rst

@@ -78,7 +78,7 @@ Exceptions to the Rule
 
 I exaggerated a little in the previous section: because overriding
 *every* superclass initializer in *every* subclass is so tedious, the
-Objective C community has identified some situations where you don't
+Objective-C community has identified some situations where you don't
 really need to override every ``init`` method:
 
 1. When you know the default zero-initialization of a class' instance

lib/IRGen/GenDecl.cpp

@@ -117,9 +117,9 @@ class CategoryInitializerVisitor
     metaclassMetadata = llvm::ConstantExpr::getBitCast(metaclassMetadata,
                                                    IGM.ObjCClassPtrTy);
 
-    // We need to make sure the Objective C runtime has initialized our
+    // We need to make sure the Objective-C runtime has initialized our
     // class. If you try to add or replace a method to a class that isn't
-    // initialized yet, the Objective C runtime will crash in the calls
+    // initialized yet, the Objective-C runtime will crash in the calls
     // to class_replaceMethod or class_addProtocol.
     Builder.CreateCall(IGM.getGetInitializedObjCClassFn(), classMetadata);
 

lib/SILGen/SILGenPoly.cpp

@@ -2740,7 +2740,7 @@ getWitnessDispatchKind(Type selfType, SILDeclRef witness, bool isFree) {
   bool isExtension = isa<ExtensionDecl>(decl->getDeclContext());
 
   // If we have a final method or a method from an extension that is not
-  // objective c, emit a static reference.
+  // Objective-C, emit a static reference.
   // A natively ObjC method witness referenced this way will end up going
   // through its native thunk, which will redispatch the method after doing
   // bridging just like we want.

lib/SILOptimizer/Transforms/StackPromotion.cpp

@@ -62,8 +62,8 @@ class StackPromoter {
   //   unreachable  bb2
   //                  \
   //
-  // We want to get bb2 as immediate post-domiator of bb1. This is not the case
-  // with the regualar post-dominator tree.
+  // We want to get bb2 as immediate post-dominator of bb1. This is not the case
+  // with the regular post-dominator tree.
   llvm::DominatorTreeBase<SILBasicBlock> PostDomTree;
 
   bool PostDomTreeValid;

lib/Sema/TypeCheckDecl.cpp

@@ -2047,7 +2047,7 @@ static void checkAccessibility(TypeChecker &TC, const Decl *D) {
   }
 }
 
-/// Figure out if a declaration should be exported to Objective C.
+/// Figure out if a declaration should be exported to Objective-C.
 static Optional<ObjCReason> shouldMarkAsObjC(TypeChecker &TC,
                                              const ValueDecl *VD,
                                              bool allowImplicit = false){

stdlib/public/core/Arrays.swift.gyb

@@ -318,7 +318,7 @@ public struct ${Self}<Element>
     if _isClassOrObjCExistential(Element.self) {
       // We are hiding the access to '_buffer.owner' behind
       // _getOwner() to help the compiler hoist uniqueness checks in
-      // the case of class or objective c existential typed array
+      // the case of class or Objective-C existential typed array
       // elements. 
       return _getOwnerWithSemanticLabel_native()
     }

stdlib/public/runtime/SwiftObject.mm

@@ -1324,7 +1324,7 @@ static void doWeakDestroy(WeakReference *addr, bool valueIsNative) {
 extern "C" Class swift_getInitializedObjCClass(Class c)
     SWIFT_CC(RegisterPreservingCC_IMPL) {
   // Used when we have class metadata and we want to ensure a class has been
-  // initialized by the Objective C runtime. We need to do this because the
+  // initialized by the Objective-C runtime. We need to do this because the
   // class "c" might be valid metadata, but it hasn't been initialized yet.
   return [c class];
 }

test/Inputs/clang-importer-sdk/swift-modules-without-ns/ObjectiveC.swift

@@ -1,6 +1,6 @@
 @_exported import ObjectiveC // Clang module
 
-// The iOS/arm64 target uses _Bool for Objective C's BOOL.  We include
+// The iOS/arm64 target uses _Bool for Objective-C's BOOL.  We include
 // x86_64 here as well because the iOS simulator also uses _Bool.
 #if ((os(iOS) || os(tvOS)) && (arch(arm64) || arch(x86_64))) || os(watchOS)
 public struct ObjCBool : Boolean {

test/Inputs/clang-importer-sdk/swift-modules/ObjectiveC.swift

@@ -1,6 +1,6 @@
 @_exported import ObjectiveC // Clang module
 
-// The iOS/arm64 target uses _Bool for Objective C's BOOL.  We include
+// The iOS/arm64 target uses _Bool for Objective-C's BOOL.  We include
 // x86_64 here as well because the iOS simulator also uses _Bool.
 #if ((os(iOS) || os(tvOS)) && (arch(arm64) || arch(x86_64))) || os(watchOS)
 public struct ObjCBool : Boolean {

test/SIL/Serialization/deserialize_objectivec.sil

@@ -1,4 +1,4 @@
-// Make sure that we can deserialize objective c.
+// Make sure that we can deserialize Objective-C.
 // RUN: %target-sil-opt %platform-sdk-overlay-dir/ObjectiveC.swiftmodule > /dev/null
 // RUN: llvm-bcanalyzer %platform-sdk-overlay-dir/ObjectiveC.swiftmodule | FileCheck %s
 

test/SILOptimizer/typed-access-tb-aa.sil

@@ -142,7 +142,7 @@ bb0:
 // Now check that a native object address may:
 //
 // 1. May alias raw pointer addresses.
-// 2. Not alias an unknown object. Objective C objects are allocated differently
+// 2. Not alias an unknown object. Objective-C objects are allocated differently
 // than Swift objects and may not alias.
 // 3. Does not alias scalar addresses. This can only occur via inttoptr and the
 // like. Since we are using type oracles we are allowed to make the assumption

tools/swift-ide-test/KnownObjCMethods.def

@@ -52,7 +52,7 @@
 //
 // OBJC_PROPERTY(ContextName, PropertyName, OptionalTypeKind)
 //
-//   Describes the optionality if the type of the Objective C property.
+//   Describes the optionality if the type of the Objective-C property.
 //
 
 #ifndef INSTANCE_METHOD