Automated fixes using check-google-doc-style (#193)

With one manual ignore in the markdown style proposal, because it's explicitly listing disallowed terms.

docs/design/code_and_name_organization/README.md

@@ -49,7 +49,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Referring to the package as `package`](#referring-to-the-package-as-package)
         -   [Remove the `library` keyword from `package` and `import`](#remove-the-library-keyword-from-package-and-import)
         -   [Rename package concept](#rename-package-concept)
-        -   [No association between the filesystem path and library/namespace](#no-association-between-the-filesystem-path-and-librarynamespace)
+        -   [No association between the file system path and library/namespace](#no-association-between-the-file-system-path-and-librarynamespace)
     -   [Libraries](#libraries-1)
         -   [Allow exporting namespaces](#allow-exporting-namespaces)
         -   [Allow importing implementation files from within the same library](#allow-importing-implementation-files-from-within-the-same-library)
@@ -765,7 +765,7 @@ These choices are made to assist human readability and tooling:
     tooling to determine what to expect.
 -   Repeating the type in the filename makes it possible to check the type
     without reading file content.
--   Repeating the type in the file content makes non-filesystem-based builds
+-   Repeating the type in the file content makes non-file-system-based builds
     possible.
 
 ## Open questions
@@ -1020,7 +1020,7 @@ Disadvantages:
     -   [Swift](https://developer.apple.com/documentation/swift_packages), as a
         distributable unit.
 
-#### No association between the filesystem path and library/namespace
+#### No association between the file system path and library/namespace
 
 Several languages create a strict association between the method for pulling in
 an API and the path to the file that provides it. For example:
@@ -1028,10 +1028,10 @@ an API and the path to the file that provides it. For example:
 -   In C++, `#include` refers to specific files without any abstraction.
     -   For example, `#include "PATH/TO/FILE.h"` means there's a file
         `PATH/TO/FILE.h`.
--   In Java, `package` and `import` both reflect filesystem structure.
+-   In Java, `package` and `import` both reflect file system structure.
     -   For example, `import PATH.TO.FILE;` means there's a file
         `PATH/TO/FILE.java`.
--   In Python, `import` requires matching filesystem structure.
+-   In Python, `import` requires matching file system structure.
     -   For example, `import PATH.TO.FILE` means there's a file
         `PATH/TO/FILE.py`.
 -   In TypeScript, `import` refers to specific files.
@@ -1053,7 +1053,7 @@ Advantages:
 -   The strict association makes it harder to move names between files without
     updating callers.
 -   If there were a strict association of paths, it would also need to handle
-    filesystem-dependent casing behaviors.
+    file system dependent casing behaviors.
     -   For example, on Windows, `project.carbon` and `Project.carbon` are
         conflicting filenames. This is exacerbated by paths, wherein a file
         `config` and a directory `Config/` would conflict, even though this
@@ -1061,15 +1061,15 @@ Advantages:
 
 Disadvantages:
 
--   A strict association between filesystem path and import path makes it easier
-    to find source files. This is used by some languages for compilation.
+-   A strict association between file system path and import path makes it
+    easier to find source files. This is used by some languages for compilation.
 -   Allows getting rid of the `package` keyword by inferring related information
-    from the filesystem path.
+    from the file system path.
 
-We are choosing to have some association between the filesystem path and library
-for API files to make it easier to find a library's files. We are not getting
-rid of the `package` keyword because we don't want to become dependent on
-filesystem structures, particularly as it would increase the complexity of
+We are choosing to have some association between the file system path and
+library for API files to make it easier to find a library's files. We are not
+getting rid of the `package` keyword because we don't want to become dependent
+on file system structures, particularly as it would increase the complexity of
 distributed builds.
 
 ### Libraries
@@ -1190,14 +1190,14 @@ Advantages:
 
 -   Clearer distinction between the package and library, increasing readability.
 -   We have chosen not to
-    [enforce filesystem paths](#strict-association-between-the-filesystem-path-and-librarynamespace)
+    [enforce file system paths](#strict-association-between-the-file-system-path-and-librarynamespace)
     in order to ease refactoring, and encouraging a mental model where they may
     match could confuse users.
 
 Disadvantages:
 
 -   Uses multiple separators, so people need to type different characters.
--   There is a preference for thinking of libraries like filesystem paths, even
+-   There is a preference for thinking of libraries like file system paths, even
     if they don't actually correspond.
 
 People like `/`, so we're going with `/`.

docs/design/name_lookup.md

@@ -67,7 +67,7 @@ reference.
 #### Alternatives
 
 This implies that other names within your own package but not declared within
-the file must be found via the package name. It isn't clear if this is the
+the file must be found by way of the package name. It isn't clear if this is the
 desirable end state. We need to consider alternatives where names from the same
 library or any library in the same package are made immediately visible within
 the package scope for unqualified name lookup.

docs/design/primitive_types.md

@@ -87,7 +87,7 @@ the need to import things gratuitously.
 
 ### String view vs owning string
 
-The right model of a string view vs. an owning string is still very much
+The right model of a string view versus an owning string is still very much
 unsettled.
 
 ### Syntax for wrapping operations

docs/design/structs.md

@@ -77,7 +77,7 @@ constraints.
 
 The type itself is a compile-time constant value. All name access is done with
 the `.` notation. Constant members (including member types and member functions
-which do not need an implicit object parameter) can be accessed via that
+which do not need an implicit object parameter) can be accessed by way of that
 constant: `AdvancedWidget.NestedType`. Other members and member functions
 needing an object parameter (or "methods") must be accessed from an object of
 the type.
@@ -99,8 +99,8 @@ special `Self` type.
 
 It may be interesting to consider separating the `self` syntax from the rest of
 the parameter pattern as it doesn't seem necessary to inject all of the special
-rules (covariance vs. contravariance, special pointer handling) for `self` into
-the general pattern matching system.
+rules (covariance versus contravariance, special pointer handling) for `self`
+into the general pattern matching system.
 
 ### Default access control level
 

docs/design/syntactic_conventions.md

@@ -65,11 +65,11 @@ like something that people will get used to with time, it may be worthwhile to
 do some user research to understand the likely reaction distribution, strength
 of reaction, and any quantifiable impact these options have on measured
 readability. We have only found one _very_ weak source of research that focused
-on the _order_ question (rather than type inference vs. explicit types or other
-questions in this space). That was a very limited PhD student's study of Java
-programmers that seemed to indicate improved latency for recalling the type of a
-given variable name with types on the left (as in C++). However, those results
-are _far_ from conclusive.
+on the _order_ question (rather than type inference versus explicit types or
+other questions in this space). That was a very limited PhD student's study of
+Java programmers that seemed to indicate improved latency for recalling the type
+of a given variable name with types on the left (as in C++). However, those
+results are _far_ from conclusive.
 
 **TODO**: Get a useful link to this PhD research (a few of us got a copy from
 the professor directly).

docs/project/commenting_guidelines.md

@@ -24,8 +24,8 @@ always try to keep feedback, even when critical, constructive and supportive.
     keep the discussion focused in one place: the GitHub pull request.
 
     -   If your comment represents a significant change to the proposal, include
-        a list of pros and cons. Even if the author disagrees with the change,
-        they can use those to document the alternative.
+        a list of advantages and disadvantages. Even if the author disagrees
+        with the change, they can use those to document the alternative.
     -   Feel free to extract long side discussions to a Discourse Forum topic,
         but make sure any important conclusions or outcomes are reflected in
         either the GitHub comments or the change itself.

docs/project/consensus_decision_making.md

@@ -91,9 +91,10 @@ weekly meeting slot, which observers may attend. Members are expected to do
 their best to keep the slot available. Meetings will be held using Google
 Hangouts Meet.
 
-Each time a team needs to make a decision, e.g., about a change to Carbon, it is
-expected that we'll try to make a decision without using a live meeting. We will
-only hold meetings when decisions cannot be resolved before the meeting.
+Each time a team needs to make a decision, for example, about a change to
+Carbon, it is expected that we'll try to make a decision without using a live
+meeting. We will only hold meetings when decisions cannot be resolved before the
+meeting.
 
 ### Agenda
 

docs/project/contribution_tools.md

@@ -74,7 +74,7 @@ To set up pre-commit, see the
 ```bash
 pip install pre-commit
 
-# From within each carbon-language git repo:
+# From within each carbon-language git repository:
 pre-commit install
 ```
 
@@ -111,7 +111,7 @@ PR and proposal file for a new proposal. It's documented in
 is a helper for scanning comments in GitHub. It's particularly intended to help
 find threads which need to be resolved.
 
-Flags can be seen with `-h`. A couple key flags to be aware of are:
+Options can be seen with `-h`. A couple key options to be aware of are:
 
 -   `--long`: Prints long output, with the full comment.
 -   `--comments-after LOGIN`: Only print threads where the final comment is not
@@ -143,7 +143,7 @@ brew install github/gh/gh
 #### GitHub Desktop
 
 [GitHub Desktop](https://desktop.github.com/) provides a UI for managing git
-repos. See the page for installation instructions.
+repositories. See the page for installation instructions.
 
 ### Vim
 

docs/project/evolution.md

@@ -253,10 +253,10 @@ community's engagement in it. Beyond the above structure, try to use
 or [BLUF](<https://en.wikipedia.org/wiki/BLUF_(communication)>) writing style to
 help readers rapidly skim the material.
 
-The proposal's pull request may include changes in the same repo. Please be
-thoughtful about how much effort you invest this way: it can help illustrate the
-intent of a proposal and avoid duplicating text in the proposal, but proposals
-may also need to be rewritten substantially or be deferred/declined.
+The proposal's pull request may include changes in the same repository. Please
+be thoughtful about how much effort you invest this way: it can help illustrate
+the intent of a proposal and avoid duplicating text in the proposal, but
+proposals may also need to be rewritten substantially or be deferred/declined.
 
 Where parts of a proposal may have several ways to address them, feel free to
 list options and mark them as "open questions". When describing an open
@@ -338,8 +338,9 @@ believe more changes are needed.
 When significant alternatives are pointed out, include them in the proposal
 regardless of whether they're adopted. The "alternatives" section should be used
 to document rejected alternatives as well as the original approach when an
-alternative is adopted, with pros and cons either way. New "open questions" may
-also be added where the author isn't confident about the best approach.
+alternative is adopted, with advantages and disadvantages either way. New "open
+questions" may also be added where the author isn't confident about the best
+approach.
 
 ##### Actions
 

docs/project/goals.md

@@ -233,7 +233,7 @@ Titus Winters writes in "Non-Atomic Refactoring and Software Sustainability":
 > compatibility over time, dealing with changes to underlying infrastructure and
 > dependencies, and working with legacy code or data. Fundamentally, it is a
 > different task to produce a programming solution to a problem (that solves the
-> current [instance] of the problem) vs. an engineering solution (that solves
+> current [instance] of the problem) versus an engineering solution (that solves
 > current instances, future instances that we can predict, and - through
 > flexibility - allows updates to solve future instances we may not be able to
 > predict).
@@ -364,8 +364,8 @@ cost.
 **Adhere to the principle of least surprise.** Defaults should match typical
 usage patterns. Implicit features should be unsurprising and expected, while
 explicit syntax should inform the reader about any behavior which might
-otherwise be surprising. The core concepts of implicit vs. explicit syntax are
-well articulated in
+otherwise be surprising. The core concepts of implicit versus explicit syntax
+are well articulated in
 [the Rust community](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html#implicit-vs-explicit),
 although we may come to different conclusions regarding the principles.
 

docs/project/pull_request_workflow.md

@@ -75,8 +75,8 @@ change seems trivial, still go through a pull request -- it'll likely be trivial
 to review. Always wait for someone else to review your pull request rather than
 just merging it, even if you have permission to do so.
 
-Our GitHub repos are configured to require pull requests and review before they
-are merged, so this rule is enforced automatically.
+Our GitHub repositories are configured to require pull requests and review
+before they are merged, so this rule is enforced automatically.
 
 ## Small, incremental changes