Fix dead links (#4525)

proposals/README.md

@@ -2,7 +2,7 @@
 
 Language proposals are living documents describing the current thinking about a given language feature.
 
-Proposals can be either *active*, *inactive*, *rejected* or *done*. *Active* proposals are stored directly in the proposals folder, *inactive* and *rejected* proposals are stored in the [inactive](proposals/inactive) and [rejected](proposals/rejected) subfolders, and *done* proposals are archived in a folder corresponding to the language version they are part of.
+Proposals can be either *active*, *inactive*, *rejected* or *done*. *Active* proposals are stored directly in the proposals folder, *inactive* and *rejected* proposals are stored in the [inactive](inactive) and [rejected](rejected) subfolders, and *done* proposals are archived in a folder corresponding to the language version they are part of.
 
 ## Lifetime of a proposal
 
@@ -12,7 +12,7 @@ The proposal may start out as an idea in a [discussion issue](https://github.com
 
 A proposal is *active* if it is moving forward through design and implementation toward an upcoming release. Once it is completely *done*, i.e. an implementation has been merged into a release and the feature has been specified, it is moved into a subdirectory corresponding to its release.
 
-If a feature turns out not to be likely to make it into the language at all, e.g. because it proves unfeasible, does not seem to add enough value or just isn't right for the language, it will be [rejected](proposals/rejected). If a feature has reasonable promise but is not currently being prioritized to work on, it may be declared [inactive](proposals/inactive) to avoid cluttering the main folder. It is perfectly fine for work to happen on inactive or rejected proposals, and for them to be resurrected later. The categories are there to reflect current design intent.
+If a feature turns out not to be likely to make it into the language at all, e.g. because it proves unfeasible, does not seem to add enough value or just isn't right for the language, it will be [rejected](rejected). If a feature has reasonable promise but is not currently being prioritized to work on, it may be declared [inactive](inactive) to avoid cluttering the main folder. It is perfectly fine for work to happen on inactive or rejected proposals, and for them to be resurrected later. The categories are there to reflect current design intent.
 
 ## Nature of a proposal
 
@@ -27,4 +27,4 @@ A proposal should follow the [proposal template](proposal-template.md). A good p
 
 Feedback and discussion happens in [discussion issues](https://github.com/dotnet/csharplang/labels/Discussion). When a new proposal is added to the proposals folder, it should be announced in a discussion issue by the champion or proposal author. 
 
- 
+ 

proposals/constant_interpolated_strings.md

@@ -86,17 +86,17 @@ Whenever an expression fulfills the requirements listed above, the expression is
 
 The compile-time evaluation of constant expressions uses the same rules as run-time evaluation of non-constant expressions, except that where run-time evaluation would have thrown an exception, compile-time evaluation causes a compile-time error to occur.
 
-Unless a constant expression is explicitly placed in an `unchecked` context, overflows that occur in integral-type arithmetic operations and conversions during the compile-time evaluation of the expression always cause compile-time errors ([Constant expressions](expressions.md#constant-expressions)).
+Unless a constant expression is explicitly placed in an `unchecked` context, overflows that occur in integral-type arithmetic operations and conversions during the compile-time evaluation of the expression always cause compile-time errors ([Constant expressions](../spec/expressions.md#constant-expressions)).
 
 Constant expressions occur in the contexts listed below. In these contexts, a compile-time error occurs if an expression cannot be fully evaluated at compile-time.
 
-*  Constant declarations ([Constants](classes.md#constants)).
-*  Enumeration member declarations ([Enum members](enums.md#enum-members)).
-*  Default arguments of formal parameter lists ([Method parameters](classes.md#method-parameters))
-*  `case` labels of a `switch` statement ([The switch statement](statements.md#the-switch-statement)).
-*  `goto case` statements ([The goto statement](statements.md#the-goto-statement)).
-*  Dimension lengths in an array creation expression ([Array creation expressions](expressions.md#array-creation-expressions)) that includes an initializer.
-*  Attributes ([Attributes](attributes.md)).
+*  Constant declarations ([Constants](../spec/classes.md#constants)).
+*  Enumeration member declarations ([Enum members](../spec/enums.md#enum-members)).
+*  Default arguments of formal parameter lists ([Method parameters](../spec/classes.md#method-parameters))
+*  `case` labels of a `switch` statement ([The switch statement](../spec/statements.md#the-switch-statement)).
+*  `goto case` statements ([The goto statement](../spec/statements.md#the-goto-statement)).
+*  Dimension lengths in an array creation expression ([Array creation expressions](../spec/expressions.md#array-creation-expressions)) that includes an initializer.
+*  Attributes ([Attributes](../spec/attributes.md)).
 
 An implicit constant expression conversion ([Implicit constant expression conversions](conversions.md#implicit-constant-expression-conversions)) permits a constant expression of type `int` to be converted to `sbyte`, `byte`, `short`, `ushort`, `uint`, or `ulong`, provided the value of the constant expression is within the range of the destination type.
 

proposals/nullable-enhanced-common-type.md

@@ -36,7 +36,7 @@ More precisely, we change the following sections of the specification (insertion
 > 
 > An *output type inference* is made *from* an expression `E` *to* a type `T` in the following way:
 > 
-> *  If `E` is an anonymous function with inferred return type  `U` ([Inferred return type](expressions.md#inferred-return-type)) and `T` is a delegate type or expression tree type with return type `Tb`, then a *lower-bound inference* ([Lower-bound inferences](expressions.md#lower-bound-inferences)) is made *from* `U` *to* `Tb`.
+> *  If `E` is an anonymous function with inferred return type  `U` ([Inferred return type](../spec/expressions.md#inferred-return-type)) and `T` is a delegate type or expression tree type with return type `Tb`, then a *lower-bound inference* ([Lower-bound inferences](../spec/expressions.md#lower-bound-inferences)) is made *from* `U` *to* `Tb`.
 > *  Otherwise, if `E` is a method group and `T` is a delegate type or expression tree type with parameter types `T1...Tk` and return type `Tb`, and overload resolution of `E` with the types `T1...Tk` yields a single method with return type `U`, then a *lower-bound inference* is made *from* `U` *to* `Tb`.
 > *  **Otherwise, if `E` is an expression with nullable value type `U?`, then a *lower-bound inference* is made *from* `U` *to* `T` and a *null bound* is added to `T`. **
 > *  Otherwise, if `E` is an expression with type `U`, then a *lower-bound inference* is made *from* `U` *to* `T`.

proposals/repeated-attributes.md

@@ -57,7 +57,7 @@ public partial bool TryGetValue([NotNullWhen(false)] out object? value) { ... }
 2. Should attributes which *do* allow multiple usages on a symbol be permitted to "opt in" to de-duplication of equivalent usages of an attribute?
 
 ### Design meetings
-#### [6th July 2020](/meetings/2020/LDM-2020-07-06.md#repeated-attributes-on-partial-members)
+#### [6th July 2020](../meetings/2020/LDM-2020-07-06.md#repeated-attributes-on-partial-members)
 The proposal is accepted.
   - Repetition of non-AllowMultiple attributes will be permitted across partial type declarations (open question 1).
   - Repeated application of AllowMultiple attributes will not change in behavior, and an "opt in" mechanism for de-duplication may be considered in a future proposal (open question 2).