Fixes paths (#45392)

Author: cshung

docs/design/coreclr/jit/JitOptimizerPlanningGuide.md

@@ -34,7 +34,7 @@ due to a few well-known issues:
    optimization change when it is eventually merged.  Source/library/runtime
    changes are in play for TechEmpower and Benchmarks Game both.
 
-Compiler micro-benchmarks (like those in our [test tree](https://github.com/dotnet/runtime/tree/master/src/coreclr/tests/src/JIT/Performance/CodeQuality))
+Compiler micro-benchmarks (like those in our [test tree](https://github.com/dotnet/runtime/tree/master/src/tests/JIT/Performance/CodeQuality))
 don't share these issues, and adding them as optimizations are implemented is
 critical for validation and regression prevention; however, micro-benchmarks
 often aren't as representative of real-world code, and therefore not as

docs/design/coreclr/jit/porting-ryujit.md

@@ -58,7 +58,7 @@ There are several steps to follow to port the JIT (some of which can be be done
   way, only very limited JIT functionality need to work, as the "base" JIT takes care of most functions.
 * Implement the basic instruction encodings. Test them using a method like `CodeGen::genArm64EmitterUnitTests()`.
 * Implement the bare minimum to get the compiler building and generating code for very simple operations, like addition.
-* Focus on the CodeGenBringUpTests (src\coreclr\tests\src\JIT\CodeGenBringUpTests), starting with the simple ones.
+* Focus on the CodeGenBringUpTests (src\tests\JIT\CodeGenBringUpTests), starting with the simple ones.
   These are designed such that for a test `XXX.cs`, there is a single interesting function named `XXX` to compile
   (that is, the name of the source file is the same as the name of the interesting function. This was done to make
   the scripts to invoke these tests very simple.). Set `COMPlus_AltJit=XXX` so the new JIT only attempts to

docs/design/coreclr/jit/ryujit-overview.md

@@ -131,7 +131,7 @@ bit vectors.
 ### Example of Post-Import IR
 
 For this snippet of code (extracted from
-[tests/src/JIT/CodeGenBringUpTests/DblRoots.cs](https://github.com/dotnet/runtime/blob/master/src/coreclr/tests/src/JIT/CodeGenBringUpTests/DblRoots.cs)), with `COMPlus_TieredCompilation=0` and using the DblRoots_ro.csproj project to compile it:
+[src/tests/JIT/CodeGenBringUpTests/DblRoots.cs](https://github.com/dotnet/runtime/blob/master/src/tests/JIT/CodeGenBringUpTests/DblRoots.cs)), with `COMPlus_TieredCompilation=0` and using the DblRoots_ro.csproj project to compile it:
 
        r1 = (-b + Math.Sqrt(b*b - 4*a*c))/(2*a);
 

docs/design/features/hw-intrinsics.md

@@ -118,7 +118,7 @@ This is an area of the JIT that could use some redesign and refactoring (https:/
 
 ## Testing
 
-The tests for the hardware intrinsics reside in the coreclr/tests/src/JIT/HardwareIntrinsics directory.
+The tests for the hardware intrinsics reside in the src/tests/JIT/HardwareIntrinsics directory.
 
-Many of the tests are generated programmatically from templates. See `coreclr\tests\src\JIT\HardwareIntrinsics\General\Shared\GenerateTests.csx`. We would like to see most, if not all, of the remaining tests converted to use this mechanism.
+Many of the tests are generated programmatically from templates. See `src\tests\JIT\HardwareIntrinsics\General\Shared\GenerateTests.csx`. We would like to see most, if not all, of the remaining tests converted to use this mechanism.
 

docs/workflow/testing/coreclr/gc-stress-run-readme.md

@@ -14,16 +14,13 @@ This is a pretty crude implementation. Feel free to improve it!
 
 It has 3 parts:
 
-- The stress framework is built from `<REPO_ROOT>\src\coreclr\tests\src\GC\Stress\Framework`
+- The stress framework is built from `<REPO_ROOT>\src\tests\GC\Stress\Framework`
 
-- The tests are built from `<REPO_ROOT>\src\coreclr\tests\src\GC\Stress\Tests`
+- The tests are built from `<REPO_ROOT>\src\tests\GC\Stress\Tests`
 
-- The config is at `<REPO_ROOT>\src\coreclr\tests\src\GC\Stress\testmix_gc.config`, this will be copied to the output folder of Framework
+- The config is at `<REPO_ROOT>\src\tests\GC\Stress\testmix_gc.config`, this will be copied to the output folder of Framework
 
-The easiest way to build the Framework+Tests is by building all tests - `<REPO_ROOT>\src\coreclr\build_test[.bat|.sh]`
-
-Sometimes there is a need (after initial build) to rebuild Framework+Tests. For example when modifying the Framework to add a new scenario or when investigating a failure.
-In such case it is possible to go directly into the the Framework directory and build manually- Ex: `dotnet build -c:debug`.
+The easiest way to build the Framework+Tests is by running `dotnet msbuild` from `<REPO_ROOT>` on `src\tests\GC\Stress\Framework\ReliabilityFramework.csproj`.
 
 # Running stress
 

docs/workflow/testing/coreclr/test-configuration.md

@@ -51,13 +51,13 @@ Therefore the managed portion of each test **must not contain**:
     * `<GCStressIncompatible>true</GCStressIncompatible>`
 * Exclude test from JIT stress runs runs by adding the following to the csproj:
     * `<JitOptimizationSensitive>true</JitOptimizationSensitive>`
-* Add NuGet references by updating the following [test project](https://github.com/dotnet/runtime/blob/master/src/coreclr/tests/src/Common/test_dependencies/test_dependencies.csproj).
+* Add NuGet references by updating the following [test project](https://github.com/dotnet/runtime/blob/master/src/tests/Common/test_dependencies/test_dependencies.csproj).
 * Get access to System.Private.CoreLib types and methods that are not exposed via public surface by adding the following to the csproj:
     * `<ReferenceSystemPrivateCoreLib>true</ReferenceSystemPrivateCoreLib>`
 * Any System.Private.CoreLib types and methods used by tests must be available for building on all platforms.
 This means there must be enough implementation for the C# compiler to find the referenced types and methods. Unsupported target platforms
 should simply `throw new PlatformNotSupportedException()` in its dummy method implementations.
-* Update exclusion list at [tests/issues.targets](https://github.com/dotnet/runtime/blob/master/src/coreclr/tests/issues.targets) if the test fails due to active bug.
+* Update exclusion list at [tests/issues.targets](https://github.com/dotnet/runtime/blob/master/src/tests/issues.targets) if the test fails due to active bug.
 
 ### Creating a C# test project
 

docs/workflow/testing/coreclr/testing.md

@@ -33,7 +33,7 @@ Note:  CoreCLR must be built prior to building an individual test. See the first
     * It is possible to explicitly run only the native test build with `build.sh/cmd skipmanaged`
 * Managed Test: Invoke `dotnet build` on the project directly. `dotnet` can be the `dotnet.sh` or `dotnet.cmd` script in the repo root.
 ```
-<runtime-repo-root>/dotnet.sh build <runtime-repo-root>/src/coreclr/tests/src/JIT/CodegenBringupTests/Array1_d.csproj /p:Configuration=Release
+<runtime-repo-root>/dotnet.sh build <runtime-repo-root>/src/tests/JIT/CodegenBringupTests/Array1_d.csproj /p:Configuration=Release
 ```
 
 ## Additional Documents

src/coreclr/scripts/superpmi.md

@@ -109,7 +109,7 @@ Example commands to create a collection (on Linux, by running the tests):
 
 ```
 # First, build the product, possibly the tests, and create a Core_Root directory.
-/Users/jashoo/runtime/src/coreclr/scripts/superpmi.py collect bash "/Users/jashoo/runtime/src/coreclr/tests/runtest.sh x64 checked"
+/Users/jashoo/runtime/src/coreclr/scripts/superpmi.py collect bash "/Users/jashoo/runtime/src/tests/runtest.sh x64 checked"
 ```
 
 The above command collects over all of the managed code called by the

src/coreclr/src/ToolBox/superpmi/readme.md

@@ -53,7 +53,7 @@ there is the `superpmi-shim-collector` binary (`.dll` or `.so` or `.dylib`).
 
 To harness collection, there is a .NET Core C# program that is built as
 part of the coreclr tests build called superpmicollect.exe
-(source: src/coreclr/tests/src/JIT/superpmi in https://github.com/dotnet/runtime repository).
+(source: src/tests/JIT/superpmi in https://github.com/dotnet/runtime repository).
 This tool also functions as a SuperPMI collection and playback unit test.
 
 The superpmicollect tool is also being moved to the jitutils repository

src/coreclr/src/tools/ILVerify/README.md

@@ -42,7 +42,7 @@ The code is split into three projects:
 
 To test the ILVerification library we have small methods checked in as .il files testing specific verification scenarios. These tests live under [src/ILVerification/tests/ILTests](../ILVerification/tests/ILTests). Tests are grouped into .il files based on functionalities they test. There is no strict policy here, the goal is to have a few dozen .il files instead of thousands containing each only a single method.
 
-The test project itself is under [src/coreclr/tests/src/ilverify](../../../tests/src/ilverify)
+The test project itself is under [src/tests/ilverify](../../../tests/ilverify)
 
  Method names in the .il files must follow the following naming convention:
 

src/tests/Interop/ReadMe.md

@@ -51,7 +51,7 @@ Testing P/Invoke has two aspects:
 
 ### Marshal API
 
-The Marshal API surface area testing is traditionally done via unit testing and far better suited in the [library test folder](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Runtime.InteropServices/tests). Cases where testing the API surface area requires native tests assets will be performed in the [coreclr test folder](https://github.com/dotnet/runtime/tree/master/src/coreclr/tests/src/Interop) repo.
+The Marshal API surface area testing is traditionally done via unit testing and far better suited in the [library test folder](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Runtime.InteropServices/tests). Cases where testing the API surface area requires native tests assets will be performed in the [coreclr test folder](https://github.com/dotnet/runtime/tree/master/src/tests/Interop) repo.
 
 ### NativeLibrary
 
@@ -60,7 +60,7 @@ This series has unit tests corresponding to `System.Runtime.NativeLibrary` APIs
 ## Common Task steps
 
 ### Adding new native project
-1) Update `coreclr/tests/src/Interop/CMakeLists.txt` to include new test asset directory.
+1) Update `src/tests/Interop/CMakeLists.txt` to include new test asset directory.
 1) Verify project builds by running `build-tests.cmd`/`build-tests.sh` from repo root.
 
 ### Adding new managed project

src/tests/run.py

@@ -927,7 +927,7 @@ def run_tests(args,
         per_test_timeout = 20*60*1000
 
     # Set __TestTimeout environment variable, which is the per-test timeout in milliseconds.
-    # This is read by the test wrapper invoker, in src\coreclr\tests\src\Common\Coreclr.TestWrapper\CoreclrTestWrapperLib.cs.
+    # This is read by the test wrapper invoker, in src\tests\Common\Coreclr.TestWrapper\CoreclrTestWrapperLib.cs.
     print("Setting __TestTimeout=%s" % str(per_test_timeout))
     os.environ["__TestTimeout"] = str(per_test_timeout)