fix some typos to cycle bots
authorNico Weber <thakis@chromium.org>
Mon, 10 Feb 2020 18:51:23 +0000 (13:51 -0500)
committerNico Weber <thakis@chromium.org>
Mon, 10 Feb 2020 18:51:23 +0000 (13:51 -0500)
clang/docs/Block-ABI-Apple.rst
clang/docs/LanguageExtensions.rst
clang/docs/SourceBasedCodeCoverage.rst

index 0cc14a3..d038cdf 100644 (file)
@@ -63,7 +63,7 @@ The following flags bits are in use thusly for a possible ABI.2010.3.16:
     enum {
         // Set to true on blocks that have captures (and thus are not true
         // global blocks) but are known not to escape for various other
-        // reasons. For backward compatiblity with old runtimes, whenever
+        // reasons. For backward compatibility with old runtimes, whenever
         // BLOCK_IS_NOESCAPE is set, BLOCK_IS_GLOBAL is set too. Copying a
         // non-escaping block returns the original block and releasing such a
         // block is a no-op, which is exactly how global blocks are handled.
index 9af49e3..adef8bb 100644 (file)
@@ -2145,7 +2145,7 @@ Checked Arithmetic Builtins
 ---------------------------
 
 Clang provides a set of builtins that implement checked arithmetic for security
-critical applications in a manner that is fast and easily expressable in C. As
+critical applications in a manner that is fast and easily expressible in C. As
 an example of their usage:
 
 .. code-block:: c
@@ -2538,7 +2538,7 @@ pointers and integers.
 These builtins can be used to avoid relying on implementation-defined behavior
 of arithmetic on integers derived from pointers.
 Additionally, these builtins retain type information and, unlike bitwise
-arithmentic, they can perform semantic checking on the alignment value.
+arithmetic, they can perform semantic checking on the alignment value.
 
 **Syntax**:
 
index 1575e4f..0e9c364 100644 (file)
@@ -107,14 +107,14 @@ relies on padding and the ability to map a file over the existing memory
 mapping which is generally only available on POSIX systems and isn't suitable
 for other platforms.
 
-On Fuchsia, we rely on the the ability to relocate counters at runtime using a
+On Fuchsia, we rely on the ability to relocate counters at runtime using a
 level of indirection. On every counter access, we add a bias to the counter
 address. This bias is stored in ``__llvm_profile_counter_bias`` symbol that's
 provided by the profile runtime and is initially set to zero, meaning no
-relocation. The runtime can map the profile into memory at abitrary location,
+relocation. The runtime can map the profile into memory at arbitrary locations,
 and set bias to the offset between the original and the new counter location,
 at which point every subsequent counter access will be to the new location,
-which allows updating profile directly akin to the continous mode.
+which allows updating profile directly akin to the continuous mode.
 
 The advantage of this approach is that doesn't require any special OS support.
 The disadvantage is the extra overhead due to additional instructions required