Spelling (#1580)

This PR corrects misspellings identified by the [check-spelling action](https://github.com/marketplace/actions/check-spelling).

The misspellings have been reported at https://github.com/jsoref/carbon-lang/commit/38a1c1640151899fd6da0442a92557f9543b6280#commitcomment-79197316

The action reports that the changes in this PR would make it happy: https://github.com/jsoref/carbon-lang/commit/173c8f9083a68aa61f7cfe94f720f1e5dc7f1ea3

Note: this PR does not include the action. If you're interested in running a spell check on every PR and push, that can be offered separately.

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

CONTRIBUTING.md

@@ -201,7 +201,7 @@ follow the Carbon documentation and coding styles.
 
     -   New features should have a documented design that has been approved
         through the [evolution process](docs/project/evolution.md). This
-        includes modifications to pre-existing designs.
+        includes modifications to preexisting designs.
     -   Bug fixes and mechanical improvements don't need this.
     -   All new features include unit tests, as they help to (a) document and
         validate concrete usage of the feature and its edge cases, and (b) guard

README.md

@@ -296,7 +296,7 @@ contribute.
     [our Carbon release post on GitHub](https://github.com/carbon-language/carbon-lang/discussions/1020)
     and [star carbon-lang](https://github.com/carbon-language/carbon-lang).
 -   To join the design discussion, join our
-    [our Github forum](https://github.com/carbon-language/carbon-lang/discussions).
+    [our GitHub forum](https://github.com/carbon-language/carbon-lang/discussions).
 -   See our [code of conduct](CODE_OF_CONDUCT.md) and
     [contributing guidelines](CONTRIBUTING.md) for information about the Carbon
     development community.

bazel/cc_toolchains/clang_cc_toolchain_config.bzl

@@ -461,7 +461,7 @@ def _impl(ctx):
                 "-fsanitize=address,undefined,nullability",
                 "-fsanitize-address-use-after-scope",
                 # We don't need the recovery behavior of UBSan as we expect
-                # builds to be clean. Not recoverying is a bit cheaper.
+                # builds to be clean. Not recovering is a bit cheaper.
                 "-fno-sanitize-recover=undefined",
                 # Don't embed the full path name for files. This limits the size
                 # and combined with line numbers is unlikely to result in many

docs/design/README.md

@@ -1401,8 +1401,8 @@ two methods `Distance` and `Offset`:
 -   Methods are defined as class functions with a `me` parameter inside square
     brackets `[`...`]` before the regular explicit parameter list in parens
     `(`...`)`.
--   Methods are called using using the member syntax, `origin.Distance(`...`)`
-    and `origin.Offset(`...`)`.
+-   Methods are called using the member syntax, `origin.Distance(`...`)` and
+    `origin.Offset(`...`)`.
 -   `Distance` computes and returns the distance to another point, without
     modifying the `Point`. This is signified using `[me: Self]` in the method
     declaration.
@@ -1440,7 +1440,7 @@ base class MyBaseClass { ... }
 ```
 
 Either kind of base class may be _extended_ to get a _derived class_. Derived
-classes are final unless they are themselved declared `base` or `abstract`.
+classes are final unless they are themselves declared `base` or `abstract`.
 Classes may only extend a single class. Carbon only supports single inheritance,
 and will use mixins instead of multiple inheritance.
 
@@ -1458,8 +1458,8 @@ by one of these three keywords:
 
 -   A method marked `virtual` has a definition in this class but not in any
     base.
--   A method marked `abstract` does not have have a definition in this class,
-    but must have a definition in any non-`abstract` derived class.
+-   A method marked `abstract` does not have a definition in this class, but
+    must have a definition in any non-`abstract` derived class.
 -   A method marked `impl` has a definition in this class, overriding any
     definition in a base class.
 
@@ -2797,7 +2797,7 @@ Carbon code and the other way around. This ability achieves two goals:
 -   Allows sharing a code and library ecosystem with C and C++.
 -   Allows incremental migration to Carbon from C and C++.
 
-Carbon's approach to interopp is most similar to
+Carbon's approach to interop is most similar to
 [Java/Kotlin interop](interoperability/philosophy_and_goals.md#other-interoperability-layers),
 where the two languages are different, but share enough of runtime model that
 data from one side can be used from the other. For example, C++ and Carbon will

docs/design/classes.md

@@ -177,8 +177,8 @@ strategies that allow operations performed through the pointer to the base type
 work independent of which derived type it actually points to. These strategies
 include:
 
--   Arranging for the the data layout of derived types to start with the data
-    layout of the base type as a prefix.
+-   Arranging for the data layout of derived types to start with the data layout
+    of the base type as a prefix.
 -   Putting a pointer to a table of function pointers, a
     [_vtable_](https://en.wikipedia.org/wiki/Virtual_method_table), as the first
     data member of the object. This allows methods to be
@@ -892,7 +892,7 @@ c.Expand(0.5);
 Assert(Math.Abs(c.Diameter() - 4.0) < 0.001);
 ```
 
--   Methods are called using using the dot `.` member syntax, `c.Diameter()` and
+-   Methods are called using the dot `.` member syntax, `c.Diameter()` and
     `c.Expand(`...`)`.
 -   `Diameter` computes and returns the diameter of the circle without modifying
     the `Circle` instance. This is signified using `[me: Self]` in the method

docs/design/code_and_name_organization/README.md

@@ -575,7 +575,7 @@ server for open source packages. Conflicts can also be addressed by renaming one
 of the packages, either at the source, or as a local modification.
 
 We do need to address the case of package names conflicting with other entity
-names. It's possible that a pre-existing entity will conflict with a new import,
+names. It's possible that a preexisting entity will conflict with a new import,
 and that renaming the entity is infeasible to rename due to existing callers.
 Alternately, the entity may be using an idiomatic name that it would contradict
 naming conventions to rename. In either case, this conflict may exist in a

docs/design/generics/details.md

@@ -2812,7 +2812,7 @@ function as an argument to a parameterized type, as in the previous case, and in
 addition the function needs the result to implement a specific interface.
 
 ```
-// Some parametized type.
+// Some parameterized type.
 class Vector(T:! Type) { ... }
 
 // Parameterized type implements interface only for some arguments.

docs/design/generics/overview.md

@@ -642,7 +642,7 @@ implement the `Negatable` interface for that type. The interfaces and rewrites
 used for a given operator may be found in the
 [expressions design](/docs/design/expressions/README.md).
 
-As a convenience, there is a shorcut for defining an implementation that
+As a convenience, there is a shortcut for defining an implementation that
 supports any type implicitly convertible to a specified type, using `like`:
 
 ```

docs/project/groups.md

@@ -60,5 +60,5 @@ escalating to the [Carbon leads](#carbon-leads). Notably, this team is _not_
 responsible for the _design_ of the language itself, only for its
 implementation.
 
--   [Github team](https://github.com/orgs/carbon-language/teams/implementation-team)
+-   [GitHub team](https://github.com/orgs/carbon-language/teams/implementation-team)
 -   Discord role: implementation-team

docs/project/principles/one_way.md

@@ -55,8 +55,8 @@ A couple examples of this in other languages are:
 
 In Carbon, we will prefer providing only one way to do a given thing. That is,
 given a syntax scenario where multiple design options are available, we will
-tend to provide _one_ option rather than than providing several and letting
-users choose. This echoes Python's principle.
+tend to provide _one_ option rather than providing several and letting users
+choose. This echoes Python's principle.
 
 Minimizing choices serves several goals:
 

docs/project/principles/safety_strategy.md

@@ -321,7 +321,7 @@ will adopt a strategy based on three build modes that target key use-cases.
 #### Debug
 
 The debug build mode targets developers who are iterating on code and running
-tests. It will emphasize detection and debugability, especially for safety
+tests. It will emphasize detection and debuggability, especially for safety
 issues.
 
 It needs to perform well enough to be run frequently by developers, but will
@@ -330,7 +330,7 @@ runtime checks for the most common safety issues, but it can make trade-offs
 that improve performance in exchange for less frequent, but still reliable,
 detection. Developers should do most of their testing in this build mode.
 
-The debug build mode will place a premium on the debugability of safety
+The debug build mode will place a premium on the debuggability of safety
 violations. Where safety checks rely on hardening instead of guaranteed safety,
 violations should be detected with a high probability per single occurrence of
 the bug. Detected bugs will be accompanied by a detailed diagnostic report to

docs/project/pull_request_workflow.md

@@ -211,7 +211,7 @@ required):
     # Update your fork (optional).
     git push
 
-    # Merge changes from upstream into your bracnh without disrpting history.
+    # Merge changes from upstream into your branch without disrupting history.
     git checkout feature-basic
     git merge trunk
     # Push to the first PR on your fork.
@@ -219,7 +219,7 @@ required):
     # Synchronize the upstream tracking branch for the first PR.
     git push upstream HEAD:pull-N-feature-basic
 
-    # Merge changes from the the first PR (now including changes from trunk)
+    # Merge changes from the first PR (now including changes from trunk)
     # without disrupting history.
     git checkout next-feature-extension
     git merge feature-basic

docs/project/roadmap.md

@@ -77,7 +77,7 @@ set of perspectives in the evolution of Carbon as possible.
 
 As a proxy for the amount of participation, we will count the number of active
 participants from each organization in 2022, with the aim that each organization
-is represented by less than 50% of all active participatnts.
+is represented by less than 50% of all active participants.
 
 There are many ways in which someone could be an active participant, and when
 the leads come to reflect on this at the end of the year, we expect this to be a

explorer/ast/impl_binding.h

@@ -48,7 +48,7 @@ class ImplBinding : public AstNode {
   // The interface being implemented.
   auto interface() const -> Nonnull<const Value*> { return iface_; }
 
-  // Required for the the ValueNode interface
+  // Required for the ValueNode interface
   auto constant_value() const -> std::optional<Nonnull<const Value*>> {
     return std::nullopt;
   }

explorer/fuzzing/fuzzer_util_test.cpp

@@ -27,7 +27,7 @@ TEST(FuzzerUtilTest, RunFuzzerOnCorpus) {
     std::stringstream contents;
     contents << file.rdbuf();
     // Parsing errors are ignored to make the fuzzer inputs less brittle as the
-    // exlorer code changes. This also matches standard fuzzer behavior.
+    // explorer code changes. This also matches standard fuzzer behavior.
     if (auto carbon_proto = ParseCarbonTextProto(contents.str());
         carbon_proto.ok()) {
       ParseAndExecute(carbon_proto->compilation_unit());

explorer/interpreter/address.h

@@ -16,7 +16,7 @@
 namespace Carbon {
 
 // An AllocationId identifies an _allocation_ produced by a Heap. An allocation
-// is analogous to the C++ notion of a complete object: the the `Value` in an
+// is analogous to the C++ notion of a complete object: the `Value` in an
 // allocation is not a sub-part of any other `Value`.
 class AllocationId {
  public:

explorer/interpreter/impl_scope.cpp

@@ -36,7 +36,7 @@ void ImplScope::Add(Nonnull<const Value*> iface,
       Add(impl.interface, deduced, impl.type, impl_bindings,
           type_checker.MakeConstraintWitnessAccess(impl_expr, i), type_checker);
     }
-    // A paremterized impl declaration doesn't contribute any equality
+    // A parameterized impl declaration doesn't contribute any equality
     // constraints to the scope. Instead, we'll resolve the equality
     // constraints by resolving a witness when needed.
     if (deduced.empty()) {

explorer/testdata/constraint/fail_nontype_self.carbon → explorer/testdata/constraint/fail_non_type_self.carbon

@@ -12,7 +12,7 @@ package ExplorerTest api;
 
 class X(T:! Type) {}
 
-// CHECK: COMPILATION ERROR: {{.*}}/explorer/testdata/constraint/fail_nontype_self.carbon:[[@LINE+1]]: `.Self` used in type of non-type binding `T`
+// CHECK: COMPILATION ERROR: {{.*}}/explorer/testdata/constraint/fail_non_type_self.carbon:[[@LINE+1]]: `.Self` used in type of non-type binding `T`
 fn F[T:! X(.Self)](x: T) {}
 
 fn Main() -> i32 { return 0; }

migrate_cpp/cpp_refactoring/matcher_test_base.h

@@ -23,7 +23,7 @@ class MatcherTestBase : public ::testing::Test {
     matchers.Register(std::make_unique<MatcherFactoryType>());
   }
 
-  // Expects that that the replacements produced by running the finder result in
+  // Expects that the replacements produced by running the finder result in
   // the specified code transformation.
   void ExpectReplacement(llvm::StringRef before, llvm::StringRef after) {
     auto factory =

proposals/p0042.md

@@ -78,7 +78,7 @@ Advantages:
 Disadvantages:
 
 -   Does not meaningfully scale beyond small group of developers with
-    pre-existing shared understanding of desired form of code.
+    preexisting shared understanding of desired form of code.
     -   Relies on relative infrequency of needing code review comments.
     -   Developers largely need to be well aligned and reliably writing code
         others would already approve.

proposals/p0044.md

@@ -876,7 +876,7 @@ There are multiple markdown editing tools.
 https://stackedit.io/
 
 StackEdit may look good on the surface, but we may effectively be restricted to
-using it as a WYSYWIG markdown editor, not for collaboration. For that, it's
+using it as a WYSIWYG markdown editor, not for collaboration. For that, it's
 simply one option amongst many, and not necessarily the best.
 
 Advantages:

proposals/p0051.md

@@ -105,8 +105,8 @@ Disadvantages:
 -   While interoperability is critical, the same is true of other goals; this
     isn't enough to determine priority.
 -   There are trade-offs between goals where there is already a consensus that
-    inteoperability will be diminished in favor of other goals, and there aren't
-    as many clear cases in the other direction.
+    interoperability will be diminished in favor of other goals, and there
+    aren't as many clear cases in the other direction.
     -   Taken to extremes, making interoperability and migration a higher
         priority than evolution would suggest that Carbon should start with C++
         and incrementally evolve from that base. We have observed areas where

proposals/p0083.md

@@ -174,7 +174,7 @@ only to the broad picture painted by the combination of those decisions, and
 that all such decisions need to be revisited by another proposal before we
 consider them to be agreed on. There is a substantial risk of anchoring how we
 think about Carbon -- we’ll just have to do our best to avoid taking this doc as
-a given when evaluating subsequent proposals. Those propopsals must justify a
+a given when evaluating subsequent proposals. Those proposals must justify a
 direction that agrees with this doc as much as one that does not agree with it.
 
 This doc sets the stage for increasingly incremental steps towards a complete

proposals/p0107.md

@@ -1169,7 +1169,7 @@ Disadvantages:
 -   Loses out on parser benefits of knowing which identifiers are being
     imported.
 -   Increases the risk of adding new features to APIs, as they may immediately
-    get imported by a user and conflict with a pre-existing name, breaking code.
+    get imported by a user and conflict with a preexisting name, breaking code.
 -   As the number of imports increases, it can become difficult to tell which
     import a particular symbol comes from, or how imports are being used.
 -   Arbitrary code inclusion can result in unexpected code execution, a way to

proposals/p0142.md

@@ -124,12 +124,12 @@ The choice to require NFC is really four choices:
     See also the discussion of [homoglyphs](#homoglyphs) below.
 
 2. Composition: we use a composed normalization form rather than a decomposed
-   normalization form. For example, `ō` is encooded as U+014D (LATIN SMALL
-   LETTER O WITH MACRON) in a composed form and as U+006F (LATIN SMALL LETTER
-   O), U+0304 (COMBINING MACRON) in a decomposed form. The composed form results
-   in smaller representations whenever the two differ, but the decomposed form
-   is a little easier for algorithmic processing (for example, typo correction
-   and homoglyph detection).
+   normalization form. For example, `ō` is encoded as U+014D (LATIN SMALL LETTER
+   O WITH MACRON) in a composed form and as U+006F (LATIN SMALL LETTER O),
+   U+0304 (COMBINING MACRON) in a decomposed form. The composed form results in
+   smaller representations whenever the two differ, but the decomposed form is a
+   little easier for algorithmic processing (for example, typo correction and
+   homoglyph detection).
 
 3. We require source files to be in our chosen form, rather than converting to
    that form as necessary.

proposals/p0157.md

@@ -893,7 +893,7 @@ struct Result(Type:$$ T, Type:$$ Error) {
 This approach has several advantages:
 
 -   It's somewhat simpler, because it uses return values instead of
-    continution-passing.
+    continuation-passing.
 -   It will be easier for the compiler to reason about, because of that
     simplicity and the somewhat narrower API surface. This may lead to better
     compiler performance, and better generated code.

proposals/p0199.md

@@ -655,7 +655,7 @@ raw strings. There are several reasons to prefer Swift-style raw strings:
 -   Swift raw strings are not a distinct language feature; rather, they are a
     generalization of non-raw strings -- non-raw strings are simply the case
     where the number of `#` characters in the delimiters and escape sequence
-    intorducer is zero.
+    introducer is zero.
 -   Permitting escape sequences even in raw strings means that there is no loss
     of functionality when using a raw string, and code changes under maintenance
     that would require use of a facility only available by way of an escape

proposals/p0285.md

@@ -109,7 +109,7 @@ are no braces, only one statement is allowed.
 ```bison
 statement:
   "if" '(' expression ')' statement optional_else
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 
 optional_else:

proposals/p0339.md

@@ -173,7 +173,7 @@ Example bison syntax for executable semantics is:
 ```bison
 statement:
   "var" expression identifier optional_assignment;
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 
 optional_assignment:

proposals/p0340.md

@@ -150,7 +150,7 @@ statement:
   WHILE '(' expression ')' statement
 | CONTINUE ';'
 | BREAK ';'
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 ```
 

proposals/p0353.md

@@ -163,7 +163,7 @@ still establish critical things to support:
 
 statement:
   FOR "(" pattern ":" expression ")" statement
-| /* pre-existing statements elided */
+| /* preexisting statements elided */
 ;
 ```
 

proposals/p0553.md

@@ -141,8 +141,8 @@ Advantage:
 
 Disadvantages:
 
--   Less explicit that the the methods of this impl definition are not
-    contributing to unqualified API of the type.
+-   Less explicit that the methods of this impl definition are not contributing
+    to unqualified API of the type.
 -   This kind of implementation is naturally referred to as "external",
     especially when contrasting with "inline impl".
 

proposals/p0676.md

@@ -176,7 +176,7 @@ var to: Vector(i64) = CastAVector(from, i64);
 -   There was no reason to prefer this over the previous option, since `<`...`>`
     is more associated with generics than `[`...`]`.
 
-Other different spellings of the `:!` position that came up during brainstroming
+Other different spellings of the `:!` position that came up during brainstorming
 but were not found to be compelling included:
 
 -   `<id>: Type`

proposals/p0680.md

@@ -67,7 +67,8 @@ these operators:
 Perl, Ruby, and Raku permit both syntaxes, giving the punctuation forms higher
 precedence and the keyword forms lower precedence. Both forms short-circuit.
 Raku also provides `andthen` and `orelse`, but these differ from `and` and `or`
-in what value is produced on short-ciruiting, not in whether they short-ciruit.
+in what value is produced on short-circuiting, not in whether they
+short-circuit.
 
 Zig provides `and`, `or`, and `!`.
 

proposals/p0702.md

@@ -76,7 +76,7 @@ For equality operators, there is some divergence but still a very strong trend:
 -   Some languages, such as Pascal and BASIC, use `<>` for inequality
     comparison. Python 2 permits this as a synonym for `!=`.
 -   Perl uses `eq` and `ne` for string comparisons; some shells and UNIX `test`
-    use `-eq` and `-ne` for for integer comparisons.
+    use `-eq` and `-ne` for integer comparisons.
 
 Some languages support multiple different kinds of equality comparison, such as
 both a value comparison (typically `==`) and an object identity comparison
@@ -448,7 +448,7 @@ Disadvantages:
     changing the semantics of the operator expression as we can no longer move
     from the operand.
 -   Both short-circuiting behavior and non-short-circuiting behavior will be
-    surprising and unintuitive to some. The short-circiuting option will
+    surprising and unintuitive to some. The short-circuiting option will
     introduce control flow without a keyword to announce it, which goes against
     our design decision to use a keyword for `and` and `or` to announce the
     control flow. The non-short-circuiting option will evaluate subexpressions

proposals/p0722.md

@@ -80,7 +80,7 @@ A wide variety of alternatives were considered:
 -   Putting the receiver pattern in a separate set of brackets. This could be an
     additional set of parens `(`...`)` before the explicit parameter list. Or
     the deduced parameters could be put in angle brackets `<`...`>` and the
-    receiver in square brackes `[`...`]`.
+    receiver in square brackets `[`...`]`.
 
 Examples:
 
@@ -168,7 +168,7 @@ concerns, however, that this parameter did not act like deduced parameters.
 ##### Receiver parameter is named `me`
 
 Having the receiver name be fixed is helpful for consistency. This benefits
-readers, and simplfies copying or moving code between functions. A fixed
+readers, and simplifies copying or moving code between functions. A fixed
 receiver name also allows us to identify the receiver pattern in the function
 declaration, and identify it as a method instead of an ordinary function
 associated with the type, like

proposals/p0777.md

@@ -481,7 +481,7 @@ Issue [#652](https://github.com/carbon-language/carbon-lang/issues/652)
 considered many variations on ways to have two different types for values
 depending on whether they represented a value with an exact type, or a value
 that could be a derived type. We ultimately decided that asking users to use
-both types would be too much congnitive overhead, and would be a usability
+both types would be too much cognitive overhead, and would be a usability
 regression from C++.
 
 ### Separate "exact" and "or derived" variations on pointers

proposals/p0875.md

@@ -483,7 +483,7 @@ separate declaration from definition may create friction, due to the familiarity
 of that feature and having their thinking about code layout shaped around it.
 Given that Carbon aims to be familiar to those coming from C++, an absence of
 forward declarations will work against that goal to some extent, although
-emiprical evidence suggests that the extent to which this is an issue varies
+empirical evidence suggests that the extent to which this is an issue varies
 widely between existing C++ developers.
 
 _Efficient and simple compilation:_ This approach leads to a simpler compilation
@@ -579,7 +579,7 @@ they need only consider prior code, and there is no possibility that a later
 source utterance could change the meaning of the code they're reading. However,
 it is rare to read code top-down, so the effect of this advantage may be modest.
 
-This advantage leads to a significant disadvantange: the behaviour of an entity
+This advantage leads to a significant disadvantage: the behaviour of an entity
 can be different at different places within a source file. For example, a type
 can be incomplete in one place and complete in another, or can fail to implement
 an interface when inspected early and then found to implement that interface

proposals/p1083.md

@@ -174,7 +174,7 @@ focus on the rationale and alternatives.
         possible value, in order to make it simple to factor out subexpressions.
 -   [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write)
     -   Using the same operators as other languages, with largely the same
-        semantics as C++, should aid readability and writeability especially for
+        semantics as C++, should aid readability and writability especially for
         those with less Carbon-specific knowledge.
     -   Performing built-in arithmetic in the larger operand type and refusing
         cases where a lossy conversion would be performed in C++ reduces the

proposals/p1084.md

@@ -166,7 +166,7 @@ interface EdgeInterface {
 // terms of `NodeBootstrap`, adding in constraints that
 // couldn't be written until `EdgeInterface` was defined.
 constraint NodeInterface {
-  extends NodeBootsrap where .EdgeType.NodeType == Self;
+  extends NodeBootstrap where .EdgeType.NodeType == Self;
 }
 ```
 

proposals/p1154.md

@@ -133,7 +133,7 @@ destructor can acquire locks before any unsynchronized writes occur.
 We didn't decide to include this approach in this proposal, since we felt like
 it would likely be too burdensome to prevent calling member functions from a
 destructor unless the developer did some extra work to mark all functions it
-transtively calls. We would consider this as a potential future extension. As
+transitively calls. We would consider this as a potential future extension. As
 noted in the design, this could be achieved by using the `partial` type.
 
 This was considered in the open discussions on

proposals/p1191.md

@@ -38,7 +38,7 @@ Carbon needs operations for working with bit representations of values.
 ## Background
 
 C++ provides four bitwise operations for Boolean algebra: complement (`~`), and
-(`&`), or (`|`), and xor (`^`). These are all useful in bit-maipulation code
+(`&`), or (`|`), and xor (`^`). These are all useful in bit-manipulation code
 (although `^` is used substantially less than the others). In addition, C++
 provides two bit-shift operators `<<` and `>>` that can perform three different
 operations: left shift, arithmetic right shift, and logical right shift. The
@@ -137,10 +137,10 @@ See changes to the design, and in particular
         be easy for programmers to accommodate, especially given that Rust's
         choice to replace `~` with `!` does not seem to be a source of sustained
         complaints.
-    -   The extensiblity support reflects the full scope of operator overloading
-        in C++, permitting separate overloading of each of the bitwise operators
-        with custom return types. This should allow smooth interoperability with
-        C++ overloaded operators.
+    -   The extensibility support reflects the full scope of operator
+        overloading in C++, permitting separate overloading of each of the
+        bitwise operators with custom return types. This should allow smooth
+        interoperability with C++ overloaded operators.
 
 ## Alternatives considered
 

proposals/p1270.md

@@ -60,7 +60,7 @@ See the pull request for the detailed change.
         project remains transparent and clear.
 -   [Software and language evolution](/docs/project/goals.md#software-and-language-evolution)
     -   Understanding the _motivations_ of the Carbon project will be important
-        for future language evolution efforst.
+        for future language evolution efforts.
 
 ## Alternatives considered
 

proposals/p1344.md

@@ -139,9 +139,8 @@ save, we suggest the following process:
 
 3.  Update any clones to use these archived remotes to avoid accidentally trying
     to interact with the new repository. Example commands assuming the remote
-    `origin` points to your fork and and `upstream` points to the main
-    repository. You may also need to adjust from the SSH-style URLs to HTTPS
-    ones to match:
+    `origin` points to your fork and `upstream` points to the main repository.
+    You may also need to adjust from the SSH-style URLs to HTTPS ones to match:
 
     ```
     git remote set-url upstream git@github.com:carbon-language/archived-carbon-lang.git git@github.com:carbon-language/carbon-lang.git

proposals/p1367.md

@@ -154,7 +154,7 @@ Advantages:
     [stacked PR](/docs/project/pull_request_workflow.md#stacking-dependent-pull-requests)
     advice.
 
-Diadvantages:
+Disadvantages:
 
 -   Retains team-specific bottlenecks: if none of a directory's owners are
     available, other contributors cannot step in.

third_party/examples/re2/re2.carbon

@@ -608,7 +608,7 @@ class RE2 {
   // Replace(). E.g. if rewrite == "foo \\2,\\1", returns 2.
   fn MaxSubmatch(rewrite: StringPiece) -> i32;
 
-  // Append the "rewrite" string, with backslash subsitutions from "vec",
+  // Append the "rewrite" string, with backslash substitutions from "vec",
   // to string "out".
   // Returns true on success.  This method can fail because of a malformed
   // rewrite string.  CheckRewriteString guarantees that the rewrite will

third_party/examples/woff2/carbon/src/font.carbon

@@ -51,7 +51,7 @@ struct Font {
   [[nodiscard]] fn FindTable(tag: uint32_t) const -> const Table*;
 };
 
-// Accomodates both singular (OTF, TTF) and collection (TTC) fonts
+// Accommodates both singular (OTF, TTF) and collection (TTC) fonts
 struct FontCollection {
   uint32_t flavor;
   uint32_t header_version;

third_party/examples/woff2/carbon/src/normalize.carbon

@@ -27,7 +27,7 @@ fn FixChecksums(font: Font*) -> bool;
 
 // Parses each of the glyphs in the font and writes them again to the glyf
 // table in normalized form, as defined by the StoreGlyph() function. Changes
-// the loca table accordigly.
+// the loca table accordingly.
 fn NormalizeGlyphs(font: Font*) -> bool;
 
 // Performs all of the normalization steps above.

toolchain/parser/parse_tree_test.cpp

@@ -366,7 +366,7 @@ TEST_F(ParseTreeTest, BasicFunctionDefinition) {
                          MatchFileEnd()}));
 }
 
-TEST_F(ParseTreeTest, FunctionDefinitionWithIdenifierInStatements) {
+TEST_F(ParseTreeTest, FunctionDefinitionWithIdentifierInStatements) {
   TokenizedBuffer tokens = GetTokenizedBuffer(
       "fn F() {\n"
       "  bar\n"

toolchain/parser/parser_impl.cpp

@@ -978,7 +978,7 @@ auto ParseTree::Parser::ParseOperatorExpression(
     if (PrecedenceGroup::GetPriority(lhs_precedence, operator_precedence) !=
         OperatorPriority::LeftFirst) {
       // Either the LHS operator and this operator are ambiguous, or the
-      // LHS operaor is a unary operator that can't be nested within
+      // LHS operator is a unary operator that can't be nested within
       // this operator. Either way, parentheses are required.
       emitter_.Emit(*position_, OperatorRequiresParentheses);
       lhs = llvm::None;

toolchain/parser/precedence.cpp

@@ -259,7 +259,7 @@ auto PrecedenceGroup::ForTrailing(TokenKind kind, bool infix)
     case TokenKind::LessEqualGreater():
       return Trailing{.level = Relational, .is_binary = true};
 
-    // Addative operators.
+    // Additive operators.
     case TokenKind::Plus():
     case TokenKind::Minus():
       return Trailing{.level = Additive, .is_binary = true};