Fix or remove invalid anchor links, adding pre-commit (#997)

Co-authored-by: josh11b <josh11b@users.noreply.github.com>

.pre-commit-config.yaml

@@ -33,7 +33,7 @@ repos:
       - id: search-and-replace
         files: '\.md$'
   - repo: https://github.com/google/pre-commit-tool-hooks
-    rev: 1d04a2848ac54d64bd6474ccec69aac45fa88414 # frozen: v1.1.1
+    rev: b7dadde912123577a1b5d4bfa279ce51ed06ee49 # frozen: v1.2.0
     hooks:
       - id: check-copyright
         args:
@@ -77,6 +77,7 @@ repos:
               .*/testdata/.*\.golden
           )$
       - id: check-google-doc-style
+      - id: check-links
       - id: markdown-toc
   - repo: https://github.com/codespell-project/codespell
     rev: 01da43d753cdff4ea7dff952b4f5317450af31e3 # frozen: v2.1.0

CODE_OF_CONDUCT.md

@@ -196,7 +196,7 @@ decision as to how to respond. Responses may include:
 
 -   Nothing, if no violation occurred or it has already been appropriately
     resolved.
--   One or more [enforcement actions](#enforcement-actions).
+-   One or more [enforcement actions](#enforcement-action-guidelines).
 -   Involvement of relevant law enforcement if appropriate.
 
 If the situation is not resolved within one week, we’ll respond to the original

docs/design/classes.md

@@ -419,10 +419,9 @@ the "main type". The methods of a mixin may also use data, methods, and
 interface implementations provided by the main type. Mixins are designed around
 implementation reuse rather than subtyping, and so don't need to use a vtable.
 
-A mixin might be an implementation detail of a [data class](#data-classes),
-[object type](#object-types), or
-[derived type of a polymorphic type](#polymorphic-types). A mixin might
-partially implement an [interface as base class](#interface-as-base-class).
+A mixin might be an implementation detail of a [data class](#data-classes), or
+[encapsulated type](#encapsulated-types). A mixin might partially implement an
+[interface as base class](#interface-as-base-class).
 
 **Examples:**
 [intrusive linked list](https://www.boost.org/doc/libs/1_63_0/doc/html/intrusive.html),

docs/design/code_and_name_organization/README.md

@@ -52,7 +52,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 Important Carbon goals for code and name organization are:
 
--   [Language tools and ecosystem](#language-tools-and-ecosystem)
+-   [Language tools and ecosystem](/docs/project/goals.md#language-tools-and-ecosystem)
 
     -   Tooling support is important for Carbon, including the possibility of a
         package manager.
@@ -295,8 +295,8 @@ This declaration is important for [implementation files](#libraries), which
 implicitly import the library's API, because it keeps the package name as an
 explicit entity in source files.
 
-Note that [imported name conflicts](#imported-name-conflicts) are handled
-differently.
+Note that [imported name conflicts](#package-and-library-name-conflicts) are
+handled differently.
 
 ### Libraries
 

docs/design/generics/appendix-coherence.md

@@ -233,5 +233,5 @@ either:
 -   there are incompatible values with types that have the same name, or
 -   it is difficult to reason about the program's behavior because it behaves
     like
-    [dynamic implementation binding](#rejected-alternative-dynamic-implementation-binding)
+    [dynamic implementation binding](#rejected-variation-dynamic-implementation-binding)
     (though perhaps with a monomorphization cost instead of a runtime cost).

docs/design/generics/goals.md

@@ -134,7 +134,8 @@ templates, so it is written as if Carbon will have its own templating system. It
 is assumed to be similar to C++ templates with some specific changes:
 
 -   It may have some limitations to be more compatible with generics, much like
-    how we [restrict overloading](#generics-instead-of-open-overloading).
+    how we
+    [restrict overloading](#generics-instead-of-open-overloading-and-adl).
 -   We likely will have a different method of selecting between different
     template instantiations, since
     [SFINAE](https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error)

docs/design/interoperability/philosophy_and_goals.md

@@ -290,7 +290,7 @@ considered necessary to address cases where a C++ library API expects users to
 inherit from a given C++ type.
 
 This might be restricted to pure interface types; see
-[the open question](#carbon-inheritance-from-non-pure-interface-c-types).
+[the open question](#carbon-type-inheritance-from-non-pure-interface-c-types).
 
 ### Support use of advanced C++ features
 

docs/project/contribution_tools.md

@@ -118,7 +118,7 @@ may mean packages _should_ be outdated, and not be upgraded.
 ### Linux only
 
 Linux-specific package managers are typically used for packages which work
-through [brew](#brew) on MacOS, but not on Linux.
+through [brew](#homebrew) on MacOS, but not on Linux.
 
 Installation instructions assume Debian- or Ubuntu-based Linux distributions
 with [apt](<https://en.wikipedia.org/wiki/APT_(software)>) available.
@@ -281,7 +281,7 @@ than a separate install. They are noted here mainly to help findability.
 the PR and proposal file for a new proposal. It's documented in
 [the proposal template](/proposals/scripts/template.md).
 
-**NOTE**: This requires installing [the gh CLI](#gh).
+**NOTE**: This requires installing [the gh CLI](#gh-cli).
 
 #### pr_comments.py
 

docs/project/principles/safety_strategy.md

@@ -173,7 +173,8 @@ build modes rather than adding more.
 Over time, safety should [evolve](../goals.md#software-and-language-evolution)
 using a hybrid compile-time and runtime safety approach to eventually provide a
 similar level of safety to a language that puts more emphasis on guaranteed
-safety, such as [Rust](#guaranteed-safety-by-default-rusts-model). However,
+safety, such as
+[Rust](#guaranteed-compile-time-memory-safety-using-borrow-checking). However,
 while Carbon may _encourage_ developers to modify code in support of more
 efficient safety checks, it will remain important to improve the safety of code
 for developers who cannot invest into safety-specific code modifications.

docs/project/pull_request_workflow.md

@@ -54,7 +54,7 @@ We work in a simple
 [trunk-based development](https://trunkbaseddevelopment.com/) model. This means
 all development activity takes place on a single common `trunk` branch in the
 repository (our default branch). We focus on
-[small, incremental changes](#small_incremental_changes) rather than feature
+[small, incremental changes](#small-incremental-changes) rather than feature
 branches or the "scaled" variations of this workflow.
 
 ### Green tests

proposals/p0107.md

@@ -673,7 +673,8 @@ Advantages:
 -   Simplifies IDEs and refactoring tools.
     -   Otherwise, these systems will need to understand the potential for
         separation of interface from implementation between multiple files.
-    -   For example, see [potential refactorings](#potential-refactorings).
+    -   For example, see
+        [potential refactorings](/docs/design/code_and_name_organization/README.md#potential-refactorings).
 
 Disadvantages:
 
@@ -885,7 +886,7 @@ Disadvantages:
 
 We are declining this approach because we desire package separation, and because
 of concerns that this will lead to an overall increase in verbosity due to the
-[preference for few child namespaces](#preference-for-few-child-namespaces),
+[preference for few child namespaces](/docs/design/code_and_name_organization/README.md#preference-for-few-child-namespaces),
 whereas this alternative benefits when `namespace` is specified more often.
 
 #### Different file type labels
@@ -936,8 +937,9 @@ Advantages:
 
 -   Allows straightforward reuse of `alias` for language consistency.
 -   Easier to add more optional arguments, which we expect to need for
-    [interoperability](#imports-from-other-languages) and
-    [URLs](#imports-from-urls).
+    [interoperability](/docs/design/code_and_name_organization/README.md#imports-from-other-languages)
+    and
+    [URLs](/docs/design/code_and_name_organization/README.md#imports-from-urls).
 -   Avoids defining keywords for optional fields, such as `library`.
     -   Interoperability and package management may add more fields long-term.
 
@@ -1010,7 +1012,7 @@ want file extensions to be meaningful for the syntax split.
 
 Instead of the file type split, we could drift further and instead have APIs in
 any file in a library, using the same kind of
-[API markup](#exporting-entities-from-an-api-file).
+[API markup](/docs/design/code_and_name_organization/README.md#exporting-entities-from-an-api-file).
 
 Advantages:
 

proposals/p0175.md

@@ -297,7 +297,7 @@ considered necessary to address cases where a C++ library API expects users to
 inherit from a given C++ type.
 
 This might be restricted to pure interface types; see
-[the open question](#carbon-inheritance-from-non-pure-interface-c-types).
+[the open question](#carbon-type-inheritance-from-non-pure-interface-c-types).
 
 #### Support use of advanced C++ features
 

proposals/p0353.md

@@ -347,7 +347,7 @@ too early to require further evaluation.
 
 Because the benefits of this alternative are debatable and would diverge from
 C++, adopting `in` would run contrary to
-[using C++ as a baseline](#c-as-a-baseline). Any divergence should be justified
+[using C++ as a baseline](#c-as-baseline). Any divergence should be justified
 and reviewed as a separate proposal.
 
 ### Multi-variable bindings

proposals/p0438.md

@@ -18,7 +18,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Other languages](#other-languages)
     -   [Forward declarations](#forward-declarations)
 -   [Proposal](#proposal)
-    -   [Functions](#functions)
+    -   [Functions](#functions-1)
     -   [Forward declarations](#forward-declarations-1)
 -   [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals)
 -   [Open questions](#open-questions)

proposals/p0818.md

@@ -177,8 +177,9 @@ work more similarly to languages with generics like Rust and Swift.
 
 ### Inline constraints instead of `.Self`
 
-We considered the possibility of using [named constraints](#named-constraints)
-instead of `.Self` for
+We considered the possibility of using
+[named constraints](/docs/design/generics/details.md#named-constraints) instead
+of `.Self` for
 [recursive constraints](/docs/design/generics/details.md#recursive-constraints).
 This comes under consideration since `.Self` outside the named constraint is the
 same as `Self` inside. However, you can't always avoid using `.Self`, since