Fixed Broken Links in Documentation (#50653)

Co-authored-by: Youssef Victor <[email protected]>
Co-authored-by: Marek Safar <[email protected]>

Author: 3 people

docs/design/coreclr/botr/guide-for-porting.md

@@ -218,7 +218,7 @@ be done.
 Notable components
 
 1.  The JIT. The jit maintains the largest concentration of architecture
-    specific logic in the stack. This is not surprising. See [Porting RyuJit](porting-ryujit.md)
+    specific logic in the stack. This is not surprising. See [Porting RyuJit](../jit/porting-ryujit.md)
     for guidance.
 
 2.  The CLR PAL. When porting to a non-Windows OS, the PAL will be the first component

docs/design/features/code-generation-strategies.md

@@ -8,7 +8,7 @@ One of the most important tasks a .NET runtime has is turning instructions for t
 
 One of the techniques that CoreCLR employs is Just in time compilation ("JIT"). This strategy translates instructions for the abstract processor into native instructions for the processor that the program is running on "just in time". The term "just in time" means that the translation happens when the need arises. For example, a method can be translated when it's first called.
 
-The actual transformation of IL into native code is handled by the code generator. Code generator is a component of the CoreCLR virtual machine that (with the help of other components of CoreCLR, such as the type system) translates IL into native code. The code generator talks to the rest of the virtual machine over a well-defined interface: this allows code generators to be relatively pluggable. The code generator used by the CoreCLR is [RyuJIT](../coreclr/botr/ryujit-overview.md). Over the years, CLR has had many other code generators serving different purposes, such as the simplified [fjit](https://github.com/SSCLI/sscli20_20060311/tree/master/clr/src/fjit), LLVM-based [LLIC](https://github.com/dotnet/llilc), or the closed-source jit32 and jit64.
+The actual transformation of IL into native code is handled by the code generator. Code generator is a component of the CoreCLR virtual machine that (with the help of other components of CoreCLR, such as the type system) translates IL into native code. The code generator talks to the rest of the virtual machine over a well-defined interface: this allows code generators to be relatively pluggable. The code generator used by the CoreCLR is [RyuJIT](../coreclr/jit/ryujit-overview.md). Over the years, CLR has had many other code generators serving different purposes, such as the simplified [fjit](https://github.com/SSCLI/sscli20_20060311/tree/master/clr/src/fjit), LLVM-based [LLIC](https://github.com/dotnet/llilc), or the closed-source jit32 and jit64.
 
 Big advantage of Just in time compilation is that the generated native code can be tailored for the specific physical processor model. RyuJIT currently uses information about the processor to e.g. unlock the use of AVX instructions on x64 processors that support it.
 

docs/design/features/tiered-compilation.md

@@ -84,7 +84,7 @@ Implementation
 
 The majority of the implementation can be located in [tieredcompilation.h](../../../src/coreclr/vm/tieredcompilation.h), and [tieredcompilation.cpp](../../../src/coreclr/vm/tieredcompilation.cpp)
 
-The call counter is implemented in [callcounter.h](../../../src/coreclr/vm/callcounter.h), and [callcounter.cpp](../../../src/coreclr/vm/callcounter.cpp)
+The call counter is implemented in [callcounting.h](../../../src/coreclr/vm/callcounting.h), and [callcounting.cpp](../../../src/coreclr/vm/callcounting.cpp)
 
 The policy that determines which methods are eligible for tiering is implemented in `MethodDesc::IsEligibleForTieredCompilation`, located in [method.hpp](../../../src/coreclr/vm/method.hpp)
 

docs/pr-guide.md

@@ -20,7 +20,7 @@ If during the code review process a merge conflict occurs the area owner is resp
 
 ## Merging Pull Requests
 
-Anyone with write access can merge a pull request manually or by setting the [auto-merge](/labels/auto-merge) label when it satisfies all of the following conditions:
+Anyone with write access can merge a pull request manually or by setting the [auto-merge](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request) label when it satisfies all of the following conditions:
 
 * The PR has been approved by at least one reviewer and any other objections are addressed.
     * You can request another review from the original reviewer.

docs/project/glossary.md

@@ -163,7 +163,7 @@ with unique characteristics were developed for .NET runtimes over the years.
 
 **Also referred to as**: R2R
 
-[ReadyToRun](.../design/coreclr/botr/readytorun-overview.md)
+[ReadyToRun](../design/coreclr/botr/readytorun-overview.md)
 is a file format used by the CoreCLR runtime to store AOT compiled code. `crossgen` is the AOT compiler that
 produces binaries in the ReadyToRun file format.
 

src/coreclr/scripts/superpmi.md

@@ -1,7 +1,7 @@
 # Documentation for the superpmi.py tool
 
 SuperPMI is a tool for developing and testing the JIT compiler.
-General information on SuperPMI can be found [here](../ToolBox/superpmi/readme.md)
+General information on SuperPMI can be found [here](../ToolBox/superpmi/readme.md).
 
 ## Overview
 

src/coreclr/tools/ILVerify/README.md

@@ -92,7 +92,7 @@ E.g.: ```SimpleAdd_Valid```
 The method name must contain 2 '`_`' characters.
  1. part: a friendly name
  2. part: must be the word 'Invalid' (Case sensitive)
- 3. part: the expected [VerifierErrors](../ILVerification/src/VerifierError.cs) as string separated by '.'. We assert on these errors; the test fails if ILVerify does not report these errors.
+ 3. part: the expected [VerifierErrors](../ILVerification/VerifierError.cs) as string separated by '.'. We assert on these errors; the test fails if ILVerify does not report these errors.
 
  E.g.: ```SimpleAdd_Invalid_ExpectedNumericType```
 

src/coreclr/tools/r2rdump/README.md

@@ -75,19 +75,19 @@ A array of RVAs. For x64, each RuntimeFunction has RVAs to the start of the asse
 
 ### READYTORUN_SECTION_METHODDEF_ENTRYPOINTS
 
-A [NativeArray](NativeArray.cs) used for finding the index of the entrypoint RuntimeFunction for each method. The NativeArray is index by is the rowId-1 of a method. Each element in the NativeArray is an offset pointing to the RuntimeFunction index.
+A [NativeArray](../aot/ILCompiler.Reflection.ReadyToRun/NativeArray.cs) used for finding the index of the entrypoint RuntimeFunction for each method. The NativeArray is index by is the rowId-1 of a method. Each element in the NativeArray is an offset pointing to the RuntimeFunction index.
 
 ### READYTORUN_SECTION_AVAILABLE_TYPES
 
-A [NativeHashtable](NativeHashtable.cs) mapping type hashcodes of types defined in the program to the rowIds. The hashcode is calculated with [ComputeNameHashCode](../../vm/typehashingalgorithms.h)(namespace) ^ [ComputeNameHashCode](../../vm/typehashingalgorithms.h)(name)
+A [NativeHashtable](../aot/ILCompiler.Reflection.ReadyToRun/NativeHashtable.cs) mapping type hashcodes of types defined in the program to the rowIds. The hashcode is calculated with [ComputeNameHashCode](../../vm/typehashingalgorithms.h)(namespace) ^ [ComputeNameHashCode](../../vm/typehashingalgorithms.h)(name)
 
 ### READYTORUN_SECTION_ATTRIBUTEPRESENCE
 
-A [NativeCuckooFilter](NativeHashtable.cs) to discover which tokens have which "System.Runtime." prefixed attributes. The System.Runtime.CompilerServices.NullableAttribute is not used in this calculation. The filter is composed of a name hash of the type name using [ComputeNameHashCode](../../vm/typehashingalgorithms.h)(namespace + name) hash combined with a hash of each token that produced it. In addition the upper 16 bits is used as the fingerprint in the filter.
+A [NativeCuckooFilter](../aot/ILCompiler.Reflection.ReadyToRun/NativeHashtable.cs) to discover which tokens have which "System.Runtime." prefixed attributes. The System.Runtime.CompilerServices.NullableAttribute is not used in this calculation. The filter is composed of a name hash of the type name using [ComputeNameHashCode](../../vm/typehashingalgorithms.h)(namespace + name) hash combined with a hash of each token that produced it. In addition the upper 16 bits is used as the fingerprint in the filter.
 
 ### READYTORUN_SECTION_INSTANCE_METHOD_ENTRYPOINTS
 
-A [NativeHashtable](NativeHashtable.cs) mapping type hashcodes of generic instances to the (methodFlags, methodRowId, list of types, runtimeFunctionId). Each type in the list of types corresponds to a generic type in the method.
+A [NativeHashtable](../aot/ILCompiler.Reflection.ReadyToRun/NativeHashtable.cs) mapping type hashcodes of generic instances to the (methodFlags, methodRowId, list of types, runtimeFunctionId). Each type in the list of types corresponds to a generic type in the method.
 
 Eg. GenericMethod<S, T>(T arg1, S arg2) instantiated for <int, UserDefinedStruct> is in the hashtable as:
 

src/libraries/System.Private.CoreLib/src/README.md

@@ -17,4 +17,4 @@ The CoreCLR specific sources can be found at [src/coreclr/System.Private.CoreLib
 
 ## System.Private.CoreLib Mono Sources
 
-The Mono specific sources can be found at [src/mono/netcore/System.Private.CoreLib](../../../mono/netcore/System.Private.CoreLib/).
+The Mono specific sources can be found at [src/mono/System.Private.CoreLib](../../../mono/System.Private.CoreLib/).

src/mono/sample/wasm/browser-profile/README.md

@@ -54,7 +54,7 @@ function saveProfile() {
 `<Import Project="$(MonoProjectRoot)\wasm\build\WasmApp.InTree.targets" />` <br/>
 `<Import Project="$(MonoProjectRoot)wasm\build\WasmApp.InTree.props" />`
 
-For more information on how to utilize WasmApp.InTree.targets/props consult the wasm build directory [README.md](../../../../wasm/build/README.md)
+For more information on how to utilize WasmApp.InTree.targets/props consult the wasm build directory [README.md](../../../wasm/README.md)
 
 2. To get the profile data, run: