Auto-update pre-commit repositories and fix. (#3427)

The version of `flake8` was too old to support with Python 3.12 -- there
is new F-string support that caused false positives sadly. The updated
version has fixes for all of these.

This in turn updates codespell which has picked up several new fixes
that actually fire in our code, so also fix everything. While we don't
do more in-depth updates to old proposals, similar to simply fixing
broken links, fixing automatically detected typos seems scalable and
fine.

All edits were automatically generated here.

Author: chandlerc

.pre-commit-config.yaml

@@ -12,7 +12,7 @@ default_language_version:
 
 repos:
   - repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: f71fa2c1f9cf5cb705f73dffe4b21f7c61470ba9 # frozen: v4.4.0
+    rev: c4a0b883114b00d8d76b479c820ce7950211c99b # frozen: v4.5.0
     hooks:
       - id: check-added-large-files
       - id: check-case-conflict
@@ -45,11 +45,11 @@ repos:
 
   # Formatters should be run late so that they can re-format any prior changes.
   - repo: https://github.com/psf/black
-    rev: 193ee766ca496871f93621d6b58d57a6564ff81b # frozen: 23.7.0
+    rev: 2a1c67e0b2f81df602ec1f6e7aeb030b9709dc7c # frozen: 23.11.0
     hooks:
       - id: black
   - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: efd8b1e16f05132acf6edcf2827eeab21e0e00db # frozen: v3.0.0
+    rev: ffb6a759a979008c0e6dff86e39f4745a2d9eac4 # frozen: v3.1.0
     hooks:
       - id: prettier
   - repo: local
@@ -119,11 +119,11 @@ repos:
         files: ^.*/BUILD$
         pass_filenames: false
   - repo: https://github.com/PyCQA/flake8
-    rev: c838a5e98878f17889cfce311e1406d252f87ec5 # frozen: 6.0.0
+    rev: 10f4af6dbcf93456ba7df762278ae61ba3120dc6 # frozen: 6.1.0
     hooks:
       - id: flake8
   - repo: https://github.com/pre-commit/mirrors-mypy
-    rev: '6e63c9e9c65e1df04465cdcda0f2490e89291f58' # frozen: v1.4.1
+    rev: '4daa14b20c0f48f472528c2b5f5bca28a18a7ce0' # frozen: v1.7.1
     hooks:
       - id: mypy
         # Use setup.cfg to match the command line.
@@ -145,7 +145,7 @@ repos:
               .*_test\.py
           )$
   - repo: https://github.com/codespell-project/codespell
-    rev: 355e50e14fd03fe83e4ed9aa0489824b150b3b58 # frozen: v2.2.5
+    rev: 6e41aba91fb32e9feb741a6258eefeb9c6e4a482 # frozen: v2.2.6
     hooks:
       - id: codespell
         args: ['-I', '.codespell_ignore', '--uri-ignore-words-list', '*']

docs/design/generics/details.md

@@ -1981,7 +1981,7 @@ checks, like `ValidDate` with the same data layout as `Date`. Or to record the
 units associated with a value, such as `Seconds` versus `Milliseconds` or `Feet`
 versus `Meters`. We should have some way of restricting the casts between a type
 and an adapter to address this use case. One possibility would be to add the
-keyword `private` before `adpat`, so you might write
+keyword `private` before `adapt`, so you might write
 `extend private adapt Date;`.
 
 ## Associated constants

docs/design/interoperability/philosophy_and_goals.md

@@ -343,11 +343,11 @@ high cost feature to achieve full parity for mixed toolchains. Requiring bridge
 code for mixed toolchains is the likely solution to avoid this cost.
 
 Note that this issue differs when considering interoperability for Carbon code
-instantiating C++ templates. The C++ templates must be in C++ headers for
-re-use, which in turn must compile with the Carbon toolchain to re-use the built
-C++ code, regardless of whether a separate C++ toolchain is in use. This may
-also be considered a constraint on mixed toolchain interoperability, but it's
-simpler to address and less likely to burden developers.
+instantiating C++ templates. The C++ templates must be in C++ headers for reuse,
+which in turn must compile with the Carbon toolchain to reuse the built C++
+code, regardless of whether a separate C++ toolchain is in use. This may also be
+considered a constraint on mixed toolchain interoperability, but it's simpler to
+address and less likely to burden developers.
 
 To summarize, developers should expect that while _most_ features will work
 equivalently for mixed toolchains, there will never be full parity.

docs/project/principles/safety_strategy.md

@@ -392,7 +392,7 @@ Strong testing is more than good test coverage. It means a combination of:
 These practices are necessary for reliable, large-scale software engineering.
 Maintaining correctness of business logic over time requires continuous and
 thorough testing. Without it, such software systems cannot be changed and
-evolved over time reliably. Carbon will re-use these practices in conjunction
+evolved over time reliably. Carbon will reuse these practices in conjunction
 with checking build modes to mitigate the limitations of Carbon's safety
 guarantees without imposing overhead on production systems.
 

explorer/interpreter/pattern_analysis.cpp

@@ -196,7 +196,7 @@ auto PatternMatrix::FirstColumnDiscriminators() const -> DiscriminatorSet {
           num_discrims = choice->declaration().alternatives().size();
           elem_size = 1;
         } else if (isa<BoolType>(type)) {
-          // `bool` behaves like a choice type with two alternativs,
+          // `bool` behaves like a choice type with two alternatives,
           // and with no nested patterns for either of them.
           num_discrims = 2;
           elem_size = 0;

migrate_cpp/rewriter_test.cpp

@@ -56,7 +56,7 @@ class Annotations {
 // Rewrites the `cpp_code`, return the Carbon equivalent. If the text has no
 // source range annotated with $[[...]]$, the entire translation unit will be
 // migrated and output. Otherwise, only the migrated output corresponding to the
-// annotated range will be be output. No more than one range may be annoated at
+// annotated range will be be output. No more than one range may be annotated at
 // all.
 //
 // This annotation mechanism is useful in that it allows us to specifically test

proposals/p0175.md

@@ -350,11 +350,11 @@ high cost feature to achieve full parity for mixed toolchains. Requiring bridge
 code for mixed toolchains is the likely solution to avoid this cost.
 
 Note that this issue differs when considering interoperability for Carbon code
-instantiating C++ templates. The C++ templates must be in C++ headers for
-re-use, which in turn must compile with the Carbon toolchain to re-use the built
-C++ code, regardless of whether a separate C++ toolchain is in use. This may
-also be considered a constraint on mixed toolchain interoperability, but it's
-simpler to address and less likely to burden developers.
+instantiating C++ templates. The C++ templates must be in C++ headers for reuse,
+which in turn must compile with the Carbon toolchain to reuse the built C++
+code, regardless of whether a separate C++ toolchain is in use. This may also be
+considered a constraint on mixed toolchain interoperability, but it's simpler to
+address and less likely to burden developers.
 
 To summarize, developers should expect that while _most_ features will work
 equivalently for mixed toolchains, there will never be full parity.

proposals/p1964.md

@@ -310,7 +310,7 @@ determined, and how we are encoding character literals. When declaring a
 character literal, the type is based on the contents of the character so that
 `var c: u8 = 'a'` is a valid character that can be converted to `u8`, in order
 to support prefix declarations we would need to extend our type system to have
-other exlpicit type checks like in C++; a UTF-16 `u'`, UTF-32 `U'`, and wide
+other explicit type checks like in C++; a UTF-16 `u'`, UTF-32 `U'`, and wide
 characters `L'`. This would be more familiar for individuals coming to Carbon
 from a C++ background, and simplify our approach for C++ Interoperability. At
 the cost of diverge from existing standards, for example

proposals/p2200.md

@@ -750,7 +750,7 @@ fn F[template T:! I](x: T) {
 -   If generic name lookup would succeed, in this example it would be because
     `G` is a member of `I`, then the result of name lookup is template validity
     dependent. This means that template instantiation may fail if `T` has a
-    member `G` different than `T.(I.G)`. Assuming it succceeds, though, it will
+    member `G` different than `T.(I.G)`. Assuming it succeeds, though, it will
     definitely have meaning determined by `I.G`. There may still be ambiguity
     making the result dependent if it is not known whether `x` is a type and
     `I.G` is a method and so has an implicit `me` parameter.