[BULK UPDATES] DocuTune - Fix build validation issues: docs-link-absolute (#6424)

* [BULK UPDATE] DocuTune - Fix build validation issues: docs-link-absolute

* Update format.md

* Update format.md

* Update format.md

* Apply suggestions from code review

Co-authored-by: Bill Wagner <wiwagn@microsoft.com>

Co-authored-by: Fred Silberberg <fred@silberberg.xyz>
Co-authored-by: Bill Wagner <wiwagn@microsoft.com>

README.md

@@ -30,7 +30,7 @@ Discussions that are short and stay on topic are much more likely to be read. If
 - Stick to the topic of the discussion. If a comment is tangential, or goes into detail on a subtopic, start a new discussion and link back.
 - Is your comment useful for others to read, or can it be adequately expressed with an emoji reaction to an existing comment?
 
-Language proposals which prevent specific syntax from occurring can be achieved with [a Roslyn analyzer](https://docs.microsoft.com/en-us/visualstudio/extensibility/getting-started-with-roslyn-analyzers). Proposals that only make existing syntax optionally illegal will be rejected by the language design committee to prevent increased language complexity.
+Language proposals which prevent specific syntax from occurring can be achieved with a [Roslyn analyzer](https://docs.microsoft.com/visualstudio/extensibility/getting-started-with-roslyn-analyzers). Proposals that only make existing syntax optionally illegal will be rejected by the language design committee to prevent increased language complexity.
 
 ## Proposals
 Once you have a fully fleshed out proposal describing a new language feature in syntactic and semantic detail, please [open an issue for it](https://github.com/dotnet/csharplang/issues/new/choose), and it will be labeled as a [Proposal](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+label%3AProposal). The comment thread on the issue can be used to hash out or briefly discuss details of the proposal, as well as pros and cons of adopting it into C#. If an issue does not meet the bar of being a full proposal, we may move it to a discussion, so that it can be "baked" further. Specific open issues or more expansive discussion with a proposal will often warrant opening a side discussion rather than cluttering the comment section on the issue.
@@ -58,7 +58,7 @@ We have a few different milestones for issues on the repo:
 * [Backlog](https://github.com/dotnet/csharplang/milestone/10) is the set of championed proposals that have been triaged, but are not being actively worked on. While discussion and ideas from the community are welcomed on these proposals, the cost of the design work and implementation review on these features are too high for us to consider community implementation until we are ready for it.
 * [Any Time](https://github.com/dotnet/csharplang/milestone/14) is the set of championed proposals that have been triaged, but are not being actively worked on and are open to community implementation. Issues in this can be in one of 2 states: needs approved specification, and needs implementation. Those that need a specification still need to be presented during LDM for approval of the spec, but we are willing to take the time to do so at our earliest convenience.
 * [Likely Never](https://github.com/dotnet/csharplang/milestone/13) is the set of proposals that the LDM has rejected from the language. Without strong need or community feedback, these proposals will not be considered in the future.
-* Numbered milestones are the set of features that have been implemented for that particular language version. For closed milestones, these are the set of things that shipped with that release. For open milestones, features can be potentially pulled later if we discover compatability or other issues as we near release.
+* Numbered milestones are the set of features that have been implemented for that particular language version. For closed milestones, these are the set of things that shipped with that release. For open milestones, features can be potentially pulled later if we discover compatibility or other issues as we near release.
 
 ## Language Design Meetings
 

meetings/2021/LDM-2021-09-15.md

@@ -21,7 +21,7 @@ have an initial conversion of an internal Microsoft C# specification of C# 3, wh
 team has converted the C# 5 specification to markdown, and is currently working to integrate the changes from our C# 6 spec into that
 version.
 
-These dual versions of the specification can confuse users. The language reference on docs.microsoft.com comes from the csharplang
+These dual versions of the specification can confuse users. The language reference on Microsoft Docs comes from the csharplang
 version of the spec, but the TC-49 version of this specification has had a number of bug fixes and is a better markdown conversion overall.
 Because of this the csharplang version of the spec gets occasional pull requests to update various things, from English spelling and
 grammar issues to actual spec bugs, but many times those issues have already been fixed in the TC-49 version of the specification. To
@@ -70,4 +70,3 @@ time with more examples of the types of code it would enable.
 
 No conclusions today. We want to see the specification PR updated with more motivating samples, including samples from real code, before
 we make any conclusions on these issues.
-

proposals/format.md

@@ -53,7 +53,7 @@ One such potential implementation is the following. Consider all `params` invoca
 could allocate an array which has a size equal to the largest `params` invocation and use that for all of the 
 invocations by creating appropriately sized `Span<T>` instances over the array. For example:
 
-``` csharp
+```csharp
 static class OneAllocation {
     static void Use(params Span<string> spans) {
         ...
@@ -69,7 +69,7 @@ static class OneAllocation {
 
 The compiler could choose to emit the body of `Go` as follows:
 
-``` csharp
+```csharp
     static void Go() {
         var args = new string[3];
         args[0] = "jaredpar";
@@ -93,7 +93,7 @@ This optimization cannot always be applied though. Even though the callee cannot
 still be captured in the caller when there is a `ref` or a `out / ref` parameter that is itself a `ref struct`
 type. 
 
-``` csharp
+```csharp
 static class SneakyCapture {
     static ref int M(params Span<T> span) => ref span[0];
 
@@ -165,7 +165,7 @@ be implemented by translating the interpolated string into the call `ValueFormat
 for `FormattableString.Create` today. The language will support all `params` options described in this document when
 looking for the most suitable `ValueFormattableString.Create` method. 
 
-``` csharp
+```csharp
 readonly struct ValueFormattableString {
     public static ValueFormattableString Create(Variant v) { ... } 
     public static ValueFormattableString Create(string s) { ... } 
@@ -185,7 +185,7 @@ class Program {
         ConsoleEx.Write(ValueFormattableString.Create((Variant)42));
         ConsoleEx.Write(ValueFormattableString.Create(
             "hello {0}", 
-            new Variant(DateTime.UtcNow));
+            new Variant(DateTime.UtcNow)));
     }
 }
 ```
@@ -225,7 +225,7 @@ The CoreFX team also has a non-allocating set of storage types for up to three `
 them: `CreateSpan` and `KeepAlive`. This means for a `params Span<Variant>` of up to three arguments the call site 
 can be entirely allocation free.
 
-``` csharp
+```csharp
 static class ZeroAllocation {
     static void Use(params Span<Variant> spans) {
         ...
@@ -239,7 +239,7 @@ static class ZeroAllocation {
 
 The `Go` method can be lowered to the following:
 
-``` csharp
+```csharp
 static class ZeroAllocation {
     static void Go() {
         Variant2 _v;
@@ -269,7 +269,7 @@ This limitation is not some fundamental restriction though but instead more an a
 to add new op codes / intrinsics which provide universal stack allocation. These could then be used to allocate the
 backing storage for most `params Span<T>` calls.
 
-``` csharp
+```csharp
 static class BetterAllocation {
     static void Use(params Span<string> spans) {
         ...
@@ -283,7 +283,7 @@ static class BetterAllocation {
 
 The `Go` method can be lowered to the following:
 
-``` csharp
+```csharp
 static class ZeroAllocation {
     static void Go() {
         Span<T> span = RuntimeIntrinsic.StackAlloc<string>(length: 2);
@@ -319,8 +319,7 @@ How we choose will likely require a deeper investigation and examination of real
 are available then it will give us this type of flexibility.
 
 ### Why not varargs? 
-The existing 
-[varargs](https://docs.microsoft.com/en-us/cpp/windows/variable-argument-lists-dot-dot-dot-cpp-cli?view=vs-2017)
+The existing [varargs](https://docs.microsoft.com/cpp/windows/variable-argument-lists-dot-dot-dot-cpp-cli)
 feature was considered here as a possible solution. This feature though is meant primarily for C++/CLI scenarios and
 has known holes for other scenarios. Additionally there is significant cost in porting this to Unix. Hence it wasn't
 seen as a viable solution.
@@ -331,4 +330,3 @@ This spec is related to the following issues:
 - https://github.com/dotnet/csharplang/issues/1757
 - https://github.com/dotnet/csharplang/issues/179
 - https://github.com/dotnet/corefxlab/pull/2595
-