Fix cross-file links in non-proposal files (#1010)

.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: b7dadde912123577a1b5d4bfa279ce51ed06ee49 # frozen: v1.2.0
+    rev: 26cc20f971cad7dee54e1fcccb960b4e19b2bdce # frozen: v1.2.1
     hooks:
       - id: check-copyright
         args:
@@ -78,6 +78,12 @@ repos:
           )$
       - id: check-google-doc-style
       - id: check-links
+        name: Check links in non-proposal files
+        exclude: ^proposals/.*$
+      - id: check-links
+        name: Check links in proposal files
+        args: ['--anchors-only']
+        files: ^proposals/.*$
       - id: markdown-toc
   - repo: https://github.com/codespell-project/codespell
     rev: 01da43d753cdff4ea7dff952b4f5317450af31e3 # frozen: v2.1.0

docs/design/expressions/as_expressions.md

@@ -166,10 +166,11 @@ The expression `x as U` is rewritten to `x.(As(U).Convert)()`.
 
 ## Alternatives considered
 
--   [Do not distinguish between safe and unsafe casts](/docs/proposals/p0845.md#merge-as-and-assume_as)
--   [Do not distinguish between `as` and implicit conversions](/docs/proposals/p0845.md#as-only-performs-implicit-conversions)
--   [Allow `iN as bool`](/docs/proposals/p0845.md#integer-to-bool-conversions)
--   [Disallow `bool as iN`](/docs/proposals/p0845.md#bool-to-integer-conversions)
+-   [Allow `as` to perform some unsafe conversions](/proposals/p0845.md#allow-as-to-perform-some-unsafe-conversions)
+-   [Allow `as` to perform two's complement truncation](/proposals/p0845.md#allow-as-to-perform-twos-complement-truncation)
+-   [`as` only performs implicit conversions](/proposals/p0845.md#as-only-performs-implicit-conversions)
+-   [Integer to bool conversions](/proposals/p0845.md#integer-to-bool-conversions)
+-   [Bool to integer conversions](/proposals/p0845.md#bool-to-integer-conversions)
 
 ## References
 

docs/design/expressions/implicit_conversions.md

@@ -281,10 +281,10 @@ types.
 
 ## Alternatives considered
 
--   [Provide lossy and non-semantics-preserving implicit conversions from C++](/docs/proposals/p0820.md#c-conversions)
--   [Provide no implicit conversions](/docs/proposals/p0820.md#no-conversions)
--   [Provide no extensibility](/docs/proposals/p0820.md#no-extensibility)
--   [Apply implicit conversions transitively](/docs/proposals/p0820.md#transitivity)
+-   [Provide lossy and non-semantics-preserving implicit conversions from C++](/proposals/p0820.md#c-conversions)
+-   [Provide no implicit conversions](/proposals/p0820.md#no-conversions)
+-   [Provide no extensibility](/proposals/p0820.md#no-extensibility)
+-   [Apply implicit conversions transitively](/proposals/p0820.md#transitivity)
 
 ## References
 

docs/design/generics/appendix-coherence.md

@@ -46,8 +46,8 @@ These last two cases are highlighted as concerns in Rust in
 Since Carbon is bundling interface implementations into types, for the
 convenience and expressiveness that provides, we satisfy those use cases by
 giving the user control over the type of a value. This means having facilities
-for defining new [compatible types](terminology#compatible-types) with different
-interface implementations, and casting between those types as needed.
+for defining new [compatible types](terminology.md#compatible-types) with
+different interface implementations, and casting between those types as needed.
 
 ## The "Hashtable Problem"
 
@@ -213,9 +213,9 @@ This has some downsides:
     type.
 
 As a result, this doesn't make sense as the default behavior for Carbon based on
-its [goals](/project/goals.md). That being said, this could be a feature added
-later as opt-in behavior to either allow users to reduce code size or support
-use cases that require dynamic dispatch.
+its [goals](/docs/project/goals.md). That being said, this could be a feature
+added later as opt-in behavior to either allow users to reduce code size or
+support use cases that require dynamic dispatch.
 
 ### Rejected variation: manual conflict resolution
 

docs/design/generics/details.md

@@ -2099,7 +2099,7 @@ class DynamicArray(T:! Type) {
 ```
 
 For context, see
-["Interface type parameters and associated types" in the generics terminology document](terminology.md#interface-type-parameters-versus-associated-types).
+["Interface type parameters and associated types" in the generics terminology document](terminology.md#interface-type-parameters-and-associated-types).
 
 **Comparison with other languages:** Both
 [Rust](https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#specifying-placeholder-types-in-trait-definitions-with-associated-types)
@@ -2149,7 +2149,7 @@ interface at most once.
 If instead you want a family of related interfaces, one per possible value of a
 type parameter, multiple of which could be implemented for a single type, you
 would use
-[parameterized interfaces](terminology.md#interface-type-parameters-versus-associated-types).
+[parameterized interfaces](terminology.md#interface-type-parameters-and-associated-types).
 To write a parameterized version of the stack interface, instead of using
 associated types, write a parameter list after the name of the interface instead
 of the associated type declaration:

docs/design/lexical_conventions/numeric_literals.md

@@ -121,7 +121,7 @@ The design provides a syntax that is deliberately close to that used both by C++
 and many other languages, so it should feel familiar to developers. However, it
 selects a reasonably minimal subset of the syntaxes. This minimal approach
 provides benefits directly in line with the goal that Carbon code should be
-[easy to read, understand, and write](../docs/project/goals.md#code-that-is-easy-to-read-understand-and-write):
+[easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write):
 
 -   Reduces unnecessary choices for programmers.
 -   Simplifies the syntax rules of the language.

docs/design/lexical_conventions/whitespace.md

@@ -21,7 +21,8 @@ The exact lexical form of Carbon whitespace has not yet been settled. However,
 Carbon will follow lexical conventions for whitespace based on
 [Unicode Annex #31](https://unicode.org/reports/tr31/). TODO: Update this once
 the precise rules are decided; see the
-[Unicode source files](/proposals/p0142.md#characters-in-identifiers) proposal.
+[Unicode source files](/proposals/p0142.md#characters-in-identifiers-and-whitespace)
+proposal.
 
 Unicode Annex #31 suggests selecting whitespace characters based on the
 characters with Unicode property `Pattern_White_Space`, which is currently these

docs/design/lexical_conventions/words.md

@@ -26,7 +26,8 @@ The exact lexical form of words has not yet been settled. However, Carbon will
 follow lexical conventions for identifiers based on
 [Unicode Annex #31](https://unicode.org/reports/tr31/). TODO: Update this once
 the precise rules are decided; see the
-[Unicode source files](/proposals/p0142.md#characters-in-identifiers) proposal.
+[Unicode source files](/proposals/p0142.md#characters-in-identifiers-and-whitespace)
+proposal.
 
 ## Keywords
 

docs/project/code_review.md

@@ -423,7 +423,7 @@ early on:
 
 1. Bring another person into the review to help address the specific issue.
    Typically they should at least be a code owner, and may usefully be a
-   [Carbon lead](groups.md#carbon-leads-1).
+   [Carbon lead](groups.md#carbon-leads).
 
 2. Ask the specific question in a broader forum, such as Discord, in order to
    get a broad set of perspectives on a particular area or issue.

docs/project/contribution_tools.md

@@ -285,8 +285,8 @@ the PR and proposal file for a new proposal. It's documented in
 
 #### pr_comments.py
 
-[pr_comments.py](/github/pr_comments.py) is a helper for scanning comments in
-GitHub. It's particularly intended to help find threads which need to be
+[pr_comments.py](/github_tools/pr_comments.py) is a helper for scanning comments
+in GitHub. It's particularly intended to help find threads which need to be
 resolved.
 
 Options can be seen with `-h`. A couple key options to be aware of are:

docs/project/design_style_guide.md

@@ -30,7 +30,7 @@ conventions for the language design, where they have been established.
 ## General
 
 The language design documentation follows the
-[style conventions](/CONTRIBUTING.html#google-docs-and-markdown) for Carbon
+[style conventions](/CONTRIBUTING.md#google-docs-and-markdown) for Carbon
 documentation.
 
 ## Linking
@@ -42,7 +42,7 @@ documentation.
 -   Links to specific sections of a proposal should link to the repository copy
     of the proposal file, using the section title or other appropriate link
     text. For example,
-    `[Painting details](/docs/proposals/p0123.md#painting-details)`
+    `[Painting details](/proposals/p0123.md#painting-details)`
 
 ## Document structure
 
@@ -75,7 +75,7 @@ that were considered, along with references to the proposals in which those
 designs were discussed. For example:
 
 ```md
--   [Paint widgets from bottom to top](/docs/proposals/p0123.md#alternatives-considered).
+-   [Paint widgets from bottom to top](/proposals/p0123.md#alternatives-considered).
 ```
 
 ### References

docs/project/groups.md

@@ -23,7 +23,7 @@ We use a mix of:
 -   [GitHub organization](https://github.com/orgs/carbon-language/people)
     -   [GitHub team: Contributors with label access](https://github.com/orgs/carbon-language/teams/contributors-with-label-access):
         Mirrors the GitHub organization for write access.
-        [Manually updated](/github/update_label_access.py).
+        [Manually updated](/github_tools/update_label_access.py).
 -   [Discord access](https://discord.com/app)
 -   [Google group](https://groups.google.com/g/carbon-lang-contributors): Grants
     Google Drive access.

docs/project/principles/low_context_sensitivity.md

@@ -153,13 +153,13 @@ in Carbon that reflect applications of this principle:
 -   Carbon doesn't provide an analogy to C++'s
     [`using namespace`](https://en.cppreference.com/w/cpp/language/namespace#Using-directives)
     or a
-    ["wildcard imports" mechanisms](/docs/design/code_and_name_organization/#broader-imports-either-all-names-or-arbitrary-code)
+    ["wildcard imports" mechanisms](/proposals/p0107.md#broader-imports-either-all-names-or-arbitrary-code)
     that merge the names from one namespace into another. Either would introduce
     ambiguity in where a name is coming from, making the code more
     context-sensitive.
 
 -   Carbon doesn't support large blocks of code
-    [inside a namespace declaration](/docs/design/code_and_name_organization/#scoped-namespaces),
+    [inside a namespace declaration](/proposals/p0107.md#scoped-namespaces),
     where the reader would have to search for the beginning of the block to see
     what namespace applies.
 

docs/project/principles/one_way.md

@@ -104,7 +104,7 @@ benefits, typically as a matter of convenience for either a common use-case or a
 particularly complex and important use-case. Some examples of why and where this
 occurs are:
 
--   For [performance](/docs/projects/goals.md#performance-critical-software), it
+-   For [performance](/docs/project/goals.md#performance-critical-software), it
     may at times be necessary to provide a specialized syntax that better
     supports optimization than a generic syntax.
 -   For

docs/project/pull_request_workflow.md

@@ -134,8 +134,7 @@ We suggest a specific workflow to address this:
     ```
 
     And create a pull request for it using the
-    [`gh`](/docs/project/contribution_tools.md#github_commandline_interface)
-    tool:
+    [`gh`](/docs/project/contribution_tools.md#gh-cli) tool:
 
     ```shell
     gh pr create

executable_semantics/README.md

@@ -24,8 +24,8 @@ considered definitive.
 
 The parser is implemented using the flex and bison parser generator tools.
 
--   [`syntax.lpp`](syntax/syntax.lpp) the lexer specification
--   [`syntax.ypp`](syntax/syntax.ypp) the grammar
+-   [`lexer.lpp`](syntax/lexer.lpp) the lexer specification
+-   [`parser.ypp`](syntax/parser.ypp) the grammar
 
 The parser translates program text into an abstract syntax tree (AST), defined
 in the [ast](ast/) subdirectory. The `UnimplementedExpression` node type can be
@@ -35,8 +35,8 @@ handling of the `UNIMPL_EXAMPLE` token for an example of how this is done, and
 see [`unimplemented_example_test.cpp`](syntax/unimplemented_example_test.cpp)
 for an example of how to test it.
 
-The [type checker](interpreter/typecheck.h) defines what it means for an AST to
-be a valid program. The type checker prints an error and exits if the AST is
+The [type checker](interpreter/type_checker.h) defines what it means for an AST
+to be a valid program. The type checker prints an error and exits if the AST is
 invalid.
 
 The parser and type checker together specify the static (compile-time)