Remove proposals dir special casing (#1170)

.pre-commit-config.yaml

@@ -116,12 +116,6 @@ repos:
               .*/testdata/.*\.golden
           )$
       - 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/.*$
 
 # Most third-party code is in submodules; local commits are excluded here.
 # We fully exclude fuzzer corpus directories as they are generated binary data.

proposals/p0107.md

@@ -125,7 +125,7 @@ in addition to the `code_and_organization.md` alternatives section.
 Right now, the `package` syntax is very package-oriented. We could instead
 eliminate package semantics from code and organization, relying only on
 libraries and removing the link to distribution. This is the
-[collapse the package concept into libraries](/docs/design/code_and_name_organization.md#collapse-the-package-concept-into-libraries)
+[collapse the package concept into libraries](#collapse-the-package-concept-into-libraries)
 alternative.
 
 Does the core team agree with the approach to packages and libraries? If not,
@@ -141,7 +141,7 @@ Right now, the `package` syntax requires the package's own name be repeated
 through code. This touches on a couple alternatives:
 
 -   Strict association between the file system path and library/namespace
--   [Referring to the package as `package`](/docs/design/code_and_name_organization.md#referring-to-the-package-as-package)
+-   [Referring to the package as `package`](#referring-to-the-package-as-package)
 
 The end result of taking both alternatives would be that:
 
@@ -179,7 +179,7 @@ The end result of taking both alternatives would be that:
         IDE tab completion to more easily determine which APIs can be used from
         a given library.
 
--   [Fast and scalable development](/docs/projects/goals.md#fast-and-scalable-development):
+-   [Fast and scalable development](/docs/project/goals.md#fast-and-scalable-development):
 
     -   The structure of libraries and imports should help enable separate
         compilation, particularly improving performance for large codebases.
@@ -1341,7 +1341,7 @@ Disadvantages:
     -   Carbon may disallow the same-line-as-code comment style used for this.
         Even if not, if we acknowledge it's a problem, we should address it
         structurally for
-        [readability](/docs/projects/goals.md#code-that-is-easy-to-read-understand-and-write).
+        [readability](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write).
     -   This is less of a problem for other scopes, such as functions, because
         they can often be broken apart until they fit on a single screen.
 

proposals/p0113.md

@@ -71,10 +71,9 @@ naming convention. The convention suggested by Google's style guide is more
 complex than necessary, in part due to its desire to not invalidate a large
 historical codebase. That is not a concern for Carbon, and there is a specific
 advantage: using and learning how the proposed naming convention for Carbon
-itself works in practice. Thus, the
-[proposal](/docs/project/cpp_style_guide.md#naming-conventions) is to replace
-the naming conventions suggested by the Google style guide with those suggested
-for Carbon.
+itself works in practice. Thus, the [proposal](/docs/project/cpp_style_guide.md)
+is to replace the naming conventions suggested by the Google style guide with
+those suggested for Carbon.
 
 The remaining suggested modifications simply consist of selecting one of several
 allowed options in order to increase consistency and modernness. Many of the

proposals/p0144.md

@@ -169,7 +169,7 @@ Similarly, `IntLiteral(x)` and `FloatLiteral(x)` convert to any sufficiently
 large floating-point type, and produce the nearest representable floating-point
 value. Conversions in which `x` lies exactly half-way between two values are
 rejected, as
-[previously decided](/docs/design/lexical_conventions/numeric_literals.md#ties).
+[previously decided](/docs/design/lexical_conventions/numeric_literals.md).
 Conversions in which `x` is outside the range of finite values of the
 floating-point type are also represented, rather than saturating to the finite
 range or producing an infinity.

proposals/p0157.md

@@ -101,7 +101,7 @@ merely an informal way for this proposal to refer to its motivating use cases,
 in much the same way that a structs proposal might refer to "value types".
 
 Carbon as currently envisioned is already capable of approximating support for
-sum types. In particular, [pattern matching](/docs/design/pattern_matching.html)
+sum types. In particular, [pattern matching](/docs/design/pattern_matching.md)
 gives us a natural way to express querying which alternative is active, and then
 performing computations on that active alternative, which as discussed above is
 the primary way of interacting with a sum type. For example, a value-or-error

proposals/p0179.md

@@ -52,8 +52,8 @@ There may be some overlap between this _language_ infrastructure and the
 _project_ infrastructure covered by the
 [admins](/docs/project/groups.md#admins). This proposal doesn't suggest a hard
 delineation between these, and if in doubt or there is disagreement, it should
-be escalated to the [core team](/docs/project/groups.md#core-team) rather than
-spending too much time defining precisely disjoint scopes.
+be escalated to the [core team](/docs/project/groups.md) rather than spending
+too much time defining precisely disjoint scopes.
 
 ## Rationale
 

proposals/p0285.md

@@ -31,9 +31,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 ## Problem
 
-`if`/`else` is noted in the [language overview](/docs/design/README.md#ifelse),
-but is provisional. Control flow is important, and `if`/`else` is basic; the
-form is similar in many languages, even if details may change.
+`if`/`else` is noted in the [language overview](/docs/design/README.md), but is
+provisional. Control flow is important, and `if`/`else` is basic; the form is
+similar in many languages, even if details may change.
 
 ## Background
 

proposals/p0339.md

@@ -295,7 +295,7 @@ compiler errors may be confusing to users. Furthermore, the place of `3` could
 be taken by an an arbitrarily complex expression; this could cause resolving the
 ambiguity between unary and binary `*` to require unbounded look-ahead,
 adversely impacting
-[code compilation time goals](/docs/project/goals.html#fast-and-scalable-development).
+[code compilation time goals](/docs/project/goals.md#fast-and-scalable-development).
 
 Consider instead the code: