Docs: Fix spacing after periods.

PiperOrigin-RevId: 353258851

site/docs/cc-toolchain-config-reference.md

@@ -43,7 +43,7 @@ You can find Starlark constructors for all structs you'll need in the process in
 When a C++ target enters the analysis phase, Bazel selects the appropriate
 `cc_toolchain` target based on the BUILD file, and obtains the
 `CcToolchainConfigInfo` provider from the target specified in the
-`cc_toolchain.toolchain_config` attribute.  The `cc_toolchain` target
+`cc_toolchain.toolchain_config` attribute. The `cc_toolchain` target
 passes this information to the C++ target through a `CcToolchainProvider`.
 
 For example, a compile or link action, instantiated by a rule such as
@@ -515,7 +515,7 @@ With Bazel, this process can instead be implemented as follows, with
 
 
 This same feature can be implemented entirely differently for Linux, which uses
-`fission`, or for Windows, which produces `.pdb` files.  For example, the
+`fission`, or for Windows, which produces `.pdb` files. For example, the
 implementation for `fission`-based debug symbol generation might look as
 follows:
 

site/docs/cpp-use-cases.md

@@ -32,9 +32,9 @@ subdirectories).
 ## Using transitive includes
 
 If a file includes a header, then the file's rule should depend on that header's
-library.  Conversely, only direct dependencies need to be specified as
-dependencies.  For example, suppose `sandwich.h` includes `bread.h` and
-`bread.h` includes `flour.h`.  `sandwich.h` doesn't include `flour.h` (who wants
+library. Conversely, only direct dependencies need to be specified as
+dependencies. For example, suppose `sandwich.h` includes `bread.h` and
+`bread.h` includes `flour.h`. `sandwich.h` doesn't include `flour.h` (who wants
 flour in their sandwich?), so the `BUILD` file would look like this:
 
 ```python
@@ -66,7 +66,7 @@ on the `flour` library.
 
 Sometimes you cannot (or do not want to) root include paths at the workspace
 root. Existing libraries might already have an include directory that doesn't
-match its path in your workspace.  For example, suppose you have the following
+match its path in your workspace. For example, suppose you have the following
 directory structure:
 
 ```
@@ -82,7 +82,7 @@ directory structure:
 
 Bazel will expect `some_lib.h` to be included as
 `legacy/some_lib/include/some_lib.h`, but suppose `some_lib.cc` includes
-`"some_lib.h"`.  To make that include path valid,
+`"some_lib.h"`. To make that include path valid,
 `legacy/some_lib/BUILD` will need to specify that the `some_lib/include`
 directory is an include directory:
 

site/docs/external.md

@@ -5,12 +5,12 @@ title: External dependencies
 
 # Working with External Dependencies
 
-Bazel can depend on targets from other projects.  Dependencies from these other
+Bazel can depend on targets from other projects. Dependencies from these other
 projects are called _external dependencies_.
 
 The `WORKSPACE` file (or `WORKSPACE.bazel` file) in the [workspace directory](build-ref.html#workspace)
-tells Bazel how to get other projects' sources.  These other projects can
-contain one or more `BUILD` files with their own targets.  `BUILD` files within
+tells Bazel how to get other projects' sources. These other projects can
+contain one or more `BUILD` files with their own targets. `BUILD` files within
 the main project can depend on these external targets by using their name from
 the `WORKSPACE` file.
 
@@ -363,7 +363,7 @@ Prefer [`http_archive`](repo/http.html#http_archive) to `git_repository` and
    [#5116](https://github.com/bazelbuild/bazel/issues/5116) for more information.
 
 
-Do not use `bind()`.  See "[Consider removing
+Do not use `bind()`. See "[Consider removing
 bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long discussion of its issues and
 alternatives.
 
@@ -376,6 +376,6 @@ A repository rule should generally be responsible for:
 -  Downloading resources from URLs.
 -  Generating or symlinking BUILD files into the external repository directory.
 
-Avoid using `repository_ctx.execute` when possible.  For example, when using a non-Bazel C++
+Avoid using `repository_ctx.execute` when possible. For example, when using a non-Bazel C++
 library that has a build using Make, it is preferable to use `repository_ctx.download()` and then
 write a BUILD file that builds it, instead of running `ctx.execute(["make"])`.

site/docs/install-windows.md

@@ -88,7 +88,7 @@ Depending on which languages you want to build, you will need:
 
 *   Common MSYS2 packages
 
-    You will likely need these to build and run targets that depend on Bash.  MSYS2 does not install
+    You will likely need these to build and run targets that depend on Bash. MSYS2 does not install
     these tools by default, so you need to install them manually. Projects that depend on Bash tools in `PATH` need this step (for example TensorFlow).
 
     Open the MSYS2 terminal and run this command:

site/docs/mobile-install.md

@@ -65,7 +65,7 @@ know how to reuse work from previous builds: it dexes every method again, even
 though only one method was changed.
 
 - Uploading data to the device. adb does not use the full bandwidth of a USB 2.0
-connection, and larger apps can take a lot of time to upload.  The entire app is
+connection, and larger apps can take a lot of time to upload. The entire app is
 uploaded, even if only small parts have changed, for example, a resource or a
 single method, so this can be a major bottleneck.
 

site/docs/output_directories.md

@@ -123,7 +123,7 @@ The directories are laid out as follows:
                 foo/bartest.log               e.g. foo/bar.log might be an output of the //foo:bartest test with
                 foo/bartest.status            foo/bartest.status containing exit status of the test (e.g.
                                               PASSED or FAILED (Exit 1), etc)
-              include/                    <== a tree with include symlinks, generated as needed.  The
+              include/                    <== a tree with include symlinks, generated as needed. The
                                               bazel-include symlinks point to here. This is used for
                                               linkstamp stuff, etc.
             host/                         <== BuildConfiguration for build host (user's workstation), for

site/docs/platforms.md

@@ -139,7 +139,7 @@ cc_library(
 ```
 
 When building for anything but 64-bit Windows we say that `:win_driver_lib` is
-incompatible.  Incompatibility is transitive. Any targets that transitively
+incompatible. Incompatibility is transitive. Any targets that transitively
 depend on an incompatible target are themselves considered incompatible.
 
 ### When are targets skipped?

site/docs/query-how-to.html

@@ -106,16 +106,16 @@ <h3 id="Aside_implicit_dependencies">Aside: implicit dependencies</h3>
 <p>Certain rules include implicit dependencies on additional libraries or tools.
 For example, to build a <code>genproto</code> rule, you need first to build the Protocol
 Compiler, so every <code>genproto</code> rule carries an implicit dependency on the
-protocol compiler.  These dependencies are not mentioned in the build file,
-but added in by the build tool.  The full set of implicit dependencies is
+protocol compiler. These dependencies are not mentioned in the build file,
+but added in by the build tool. The full set of implicit dependencies is
   currently undocumented. Using <code>--noimplicit_deps</code> allows you to filter out
   these deps from your query results.
 
 <h2 id="Reverse_Dependencies">Reverse dependencies</h2>
 
-<p>You might want to know the set of targets that depends on some target.  e.g.,
+<p>You might want to know the set of targets that depends on some target. e.g.,
 if you're going to change some code, you might want to know what other code
-you're about to break.  You can use <code>rdeps(u, x)</code> to find the reverse
+you're about to break. You can use <code>rdeps(u, x)</code> to find the reverse
 dependencies of the targets in <code>x</code> within the transitive closure of <code>u</code>.</p>
 
 Bazel's <a href="query.html#sky-query">Sky Query</a>
@@ -258,7 +258,7 @@ <h4 id="Why_does_bar_depend_on_groups">Why does <code>bar</code> depend on <code
 
 <p>Once you have the results of this query, you will often find that a single
 target stands out as being an unexpected or egregious and undesirable
-dependency of <code>bar</code>.  The query can then be further refined to:</p>
+dependency of <code>bar</code>. The query can then be further refined to:</p>
 
 <h4 id="Show_me_a_path_from_docker_updater">Show me a path from <code>docker/updater:updater_systest</code> (a <code>py_test</code>) to some <code>cc_library</code> that it depends upon:</h4>
 
@@ -268,7 +268,7 @@ <h4 id="Show_me_a_path_from_docker_updater">Show me a path from <code>docker/upd
 <h4 id="Why_does_library_photos_frontend">Why does library <code>//photos/frontend:lib</code> depend on two variants of the same library <code>//third_party/jpeglib</code> and <code>//third_party/jpeg</code>?</h4>
 
 <p>This query boils down to: "show me the subgraph of <code>//photos/frontend:lib</code> that
-depends on both libraries".  When shown in topological order, the last element
+depends on both libraries". When shown in topological order, the last element
 of the result is the most likely culprit.</p>
 
 <pre>bazel query 'allpaths(//photos/frontend:lib, //third_party/jpeglib)
@@ -314,7 +314,7 @@ <h4 id="How_many_sequential_steps_are_th">How many sequential steps are there in
 <p>Unfortunately, the query language can't currently give you the longest path
 from x to y, but it can find the (or rather <em>a</em>) most distant node from the
 starting point, or show you the <em>lengths</em> of the longest path from x to every
-y that it depends on.  Use <code>maxrank</code>:</p>
+y that it depends on. Use <code>maxrank</code>:</p>
 
 <pre>bazel query 'deps(//foo-tests)' --output maxrank | tail -1
 85 //third_party/zlib:zutil.c</pre>