Fix up a bunch of repo references in docs (#60)

This is just prelminary, as all of the docs need to be rationalized with each other now that they're all in the same repo.  But it at least keeps most of the links working for now.

src/coreclr/build-test.cmd

@@ -320,7 +320,7 @@ if defined __SkipManaged goto SkipManagedBuild
 echo %__MsgPrefix%Starting the Managed Tests Build
 
 if not defined VSINSTALLDIR (
-    echo %__ErrMsgPrefix%%__MsgPrefix%Error: build-test.cmd should be run from a Visual Studio Command Prompt.  Please see https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/developer-guide.md for build instructions.
+    echo %__ErrMsgPrefix%%__MsgPrefix%Error: build-test.cmd should be run from a Visual Studio Command Prompt.  Please see https://github.com/dotnet/runtime/blob/master/docs/coreclr/project-docs/developer-guide.md for build instructions.
     exit /b 1
 )
 set __AppendToLog=false
@@ -647,7 +647,7 @@ of the previous version to "%VSINSTALLDIR%" and then build.
 REM DIA SDK not included in Express editions
 echo Visual Studio Express does not include the DIA SDK. ^
 You need Visual Studio 2017 or 2019 (Community is free).
-echo See: https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/developer-guide.md#prerequisites
+echo See: https://github.com/dotnet/runtime/blob/master/docs/coreclr/project-docs/developer-guide.md#prerequisites
 exit /b 1
 
 :PrecompileFX

src/coreclr/build.cmd

@@ -1078,5 +1078,5 @@ of the previous version to "%VSINSTALLDIR%" and then build.
 REM DIA SDK not included in Express editions
 echo Visual Studio Express does not include the DIA SDK. ^
 You need Visual Studio 2017 or 2019 (Community is free).
-echo See: https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/developer-guide.md#prerequisites
+echo See: https://github.com/dotnet/runtime/blob/master/docs/coreclr/project-docs/developer-guide.md#prerequisites
 exit /b 1

src/coreclr/scripts/superpmi.md

 ### An overview of using superpmi.py
 -------------------------
 
-General information on [SuperPMI](https://github.com/dotnet/coreclr/blob/master/src/ToolBox/superpmi/readme.txt)
+General information on [SuperPMI](https://github.com/dotnet/runtime/blob/master/src/coreclr/ToolBox/superpmi/readme.txt)
 
 ------------------------
 
@@ -30,11 +30,11 @@ Although SuperPMI has many uses, setup and use of SuperPMI is not always trivial
 
 See the table above for locations of default collections that exist. If there is an mch file that exists, then SuperPMI will automatically download and setup the mch using that location. Please note that, it is possible that the collection is out of date, or there is a jitinterface change which makes the collection invalid. If this is the case, then in order to use the tool a collection will have to be done manually. In order to reproduce the default collections, please see below for what command the default collections are done with.
 
-`/Users/jashoo/coreclr/build.sh x64 checked`
+`/Users/jashoo/runtime/src/coreclr/build.sh x64 checked`
 
-`/Users/jashoo/coreclr/build-test.sh x64 checked -priority1`
+`/Users/jashoo/runtime/src/coreclr/build-test.sh x64 checked -priority1`
 
-`/Users/jashoo/coreclr/scripts/superpmi.py collect bash "/Users/jashoo/coreclr/tests/runtest.sh x64 checked" --skip-cleanup`
+`/Users/jashoo/runtime/src/coreclr/scripts/superpmi.py collect bash "/Users/jashoo/runtime/src/coreclr/tests/runtest.sh x64 checked" --skip-cleanup`
 
 **Collect**
 
@@ -63,4 +63,4 @@ SuperPMI replay supports faster assertion checking over a collection than runnin
 
 SuperPMI will take two different JITs, a baseline and diff JIT and run the compiler accross all the methods in the mch file. It uses coredistools to do a binary difference of the two different outputs. Note that sometimes the binary will differ, and SuperPMI will be run once again dumping the asm that was output in text format. Then the text will be diffed, if there are differences, you should look for text differences. If there are some then it is worth investigating the asm differences.
 
-It is worth noting as well that SuperPMI gives more stable instructions retired counters for the JIT.
\ No newline at end of file
+It is worth noting as well that SuperPMI gives more stable instructions retired counters for the JIT.

src/coreclr/setup_vs_tools.cmd

@@ -31,7 +31,7 @@ echo Visual Studio 2017 or later not found
 :call_vs
 if not exist "%_VSCOMNTOOLS%" (
     echo %__MsgPrefix%Error: Visual Studio 2017 or 2019 required.
-    echo        Please see https://github.com/dotnet/coreclr/blob/master/Documentation/building/windows-instructions.md for build instructions.
+    echo        Please see https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/windows-instructions.md for build instructions.
     exit /b 1
 )
 echo %__MsgPrefix%"%_VSCOMNTOOLS%\VsDevCmd.bat"

src/coreclr/src/jit/compiler.cpp

@@ -4456,7 +4456,7 @@ void Compiler::compFunctionTraceEnd(void* methodCodePtr, ULONG methodCodeSize, b
 // code:CILJit::compileMethod function.
 //
 // For an overview of the structure of the JIT, see:
-//   https://github.com/dotnet/coreclr/blob/master/Documentation/botr/ryujit-overview.md
+//   https://github.com/dotnet/runtime/blob/master/docs/coreclr/botr/ryujit-overview.md
 //
 void Compiler::compCompile(void** methodCodePtr, ULONG* methodCodeSize, JitFlags* compileFlags)
 {

src/coreclr/src/jit/conventions.txt

@@ -3,7 +3,7 @@ Coding Conventions" document, that can be used as a template when writing new
 comments in the JIT source code. The definitive coding conventions document is
 located here:
 
-https://github.com/dotnet/coreclr/blob/master/Documentation/coding-guidelines/clr-jit-coding-conventions.md
+https://github.com/dotnet/runtime/blob/master/docs/coreclr/coding-guidelines/clr-jit-coding-conventions.md
 
 
 ********** Section 7.1.5 TODO comments

src/coreclr/src/vm/eetoprofinterfaceimpl.cpp

@@ -16,7 +16,7 @@
 // PLEASE READ!
 //
 // There are strict rules for how to implement ICorProfilerCallback* wrappers.  Please read
-// https://github.com/dotnet/coreclr/blob/master/Documentation/botr/profilability.md
+// https://github.com/dotnet/runtime/blob/master/docs/coreclr/botr/profilability.md
 // to understand the rules and why they exist.
 //
 // As a reminder, here is a short summary of your responsibilities.  Every PUBLIC

src/coreclr/src/vm/proftoeeinterfaceimpl.cpp

@@ -17,7 +17,7 @@
 // PLEASE READ!
 //
 // There are strict rules for how to implement ICorProfilerInfo* methods.  Please read
-// https://github.com/dotnet/coreclr/blob/master/Documentation/botr/profilability.md
+// https://github.com/dotnet/runtime/blob/master/docs/coreclr/botr/profilability.md
 // to understand the rules and why they exist.
 //
 // As a reminder, here is a short summary of your responsibilities.  Every PUBLIC

src/coreclr/tests/runtest.py

@@ -33,8 +33,8 @@
 # standard please pass the -test_native_bin_location flag to the script.
 #
 # Use the instructions here:
-#    https://github.com/dotnet/coreclr/blob/master/Documentation/building/windows-test-instructions.md 
-#    https://github.com/dotnet/coreclr/blob/master/Documentation/building/unix-test-instructions.md
+#    https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/windows-test-instructions.md 
+#    https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/unix-test-instructions.md
 #
 ################################################################################
 ################################################################################

src/coreclr/tests/src/Interop/ReadMe.md

@@ -10,7 +10,7 @@ There should be no more than **1** project type per folder (i.e. a folder can co
 
 Ancillary source assets for all tests should be located in `Interop/common` and can be easily added to all managed tests via the `Interop.settings.targets` file or native tests via `Interop.cmake`.
 
-A common pattern for testing is using the `Assert` utilities found in the `CoreFX` repo. This class is part of the `CoreCLRTestLibrary` which is included in all test projects by the `Interop.settings.targets` import. In order to use, add the following `using TestLibrary;` in the relevant test file.
+A common pattern for testing is using the `Assert` utilities. This class is part of the `CoreCLRTestLibrary` which is included in all test projects by the `Interop.settings.targets` import. In order to use, add the following `using TestLibrary;` in the relevant test file.
 
 ### Managed
 
@@ -55,7 +55,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 [CoreFX](https://github.com/dotnet/corefx/tree/master/src/System.Runtime.InteropServices/tests) repo. Cases where testing the API surface area requires native tests assets will be performed in the [CoreCLR](https://github.com/dotnet/coreclr/tree/master/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/coreclr/tests/src/Interop) repo.
 
 ### NativeLibrary 
 
@@ -69,4 +69,4 @@ This series has unit tests corresponding to `System.Runtime.NativeLibrary` APIs
 
 ### Adding new managed project
 1) The build system automatically discovers managed test projects.
-1) Verify project builds by running `build-tests.cmd`/`build-tests.sh` from repo root.
\ No newline at end of file
+1) Verify project builds by running `build-tests.cmd`/`build-tests.sh` from repo root.

src/coreclr/tests/src/JIT/superpmi/runtests.sh

@@ -2,7 +2,7 @@
 
 # Run CoreCLR OSS tests on Linux or Mac
 # Use the instructions here:
-#    https://github.com/dotnet/coreclr/blob/master/Documentation/building/unix-test-instructions.md
+#    https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/unix-test-instructions.md
 #
 # Summary:
 # 1. On Linux/Mac, in coreclr, ./build.sh

src/installer/corehost/build.cmd

@@ -66,7 +66,7 @@ if "%VisualStudioVersion%"=="16.0" (
 :MissingVersion
 :: Can't find VS 2017, 2019
 echo Error: Visual Studio 2017 or 2019 required
-echo        Please see https://github.com/dotnet/core-setup/tree/master/Documentation/building/windows-instructions.md for build instructions.
+echo        Please see https://github.com/dotnet/runtime/tree/master/docs/installer/building/windows-instructions.md for build instructions.
 exit /b 1
 
 :VS2019
@@ -124,7 +124,7 @@ of previous version to "%VSINSTALLDIR%" and then resume build.
 :: DIA SDK not included in Express editions
 echo Visual Studio 2013 Express does not include the DIA SDK. ^
 You need Visual Studio 2013+ (Community is free).
-echo See: https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/developer-guide.md#prerequisites
+echo See: https://github.com/dotnet/runtime/blob/master/docs/coreclr/project-docs/developer-guide.md#prerequisites
 exit /b 1
 
 :GenVSSolution

src/installer/pkg/packaging/osx/hostfxr/resources/cs.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/de.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/en.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/es.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/fr.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/it.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/ja.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/ko.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/pl.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/pt-br.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/ru.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/tr.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/zh-hans.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/installer/pkg/packaging/osx/hostfxr/resources/zh-hant.lproj/conclusion.html

-
+
 <!DOCTYPE html>
 <html lang="en">
 <head>
@@ -15,7 +15,7 @@
         <p>
         In order to be able to use .NET Core on OS X, you need to install <b>OpenSSL</b> version <b>1.0.1/1.0.2</b>. 
         There are many ways to install/update your libssl. Using <a href="https://brew.sh">Homebrew</a> is the easiest. 
-        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/coreclr/blob/master/Documentation/building/osx-instructions.md#openssl">on this page</a>.
+        You can view the instructions <a href="http://brewformulas.org/Openssl">here</a> or if you're updating, <a href="https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/osx-instructions.md#openssl">on this page</a>.
         </p>
         </div>
 </body>

src/libraries/Common/src/System/Net/Http/Http2/CopyToCoreFx.cmd

-@ECHO OFF
-SETLOCAL
-
-if not [%1] == [] (set remote_repo=%1) else (set remote_repo=%COREFX_REPO%)
-
-IF [%remote_repo%] == [] (
-  echo The 'COREFX_REPO' environment variable or command line parameter is not set, aborting.
-  exit /b 1
-)
-
-echo COREFX_REPO: %remote_repo%
-
-robocopy . %remote_repo%\src\Common\src\System\Net\Http\Http2 /MIR
-robocopy .\..\test\Shared.Tests\Http2 %remote_repo%\src\Common\tests\Tests\System\Net\Http2 /MIR

src/libraries/Common/src/System/Net/Http/Http2/CopyToRuntime.cmd

+@ECHO OFF
+SETLOCAL
+
+if not [%1] == [] (set remote_repo=%1) else (set remote_repo=%RUNTIME_REPO%)
+
+IF [%remote_repo%] == [] (
+  echo The 'RUNTIME_REPO' environment variable or command line parameter is not set, aborting.
+  exit /b 1
+)
+
+echo RUNTIME_REPO: %remote_repo%
+
+robocopy . %remote_repo%\src\libraries\Common\src\System\Net\Http\Http2 /MIR
+robocopy .\..\test\Shared.Tests\Http2 %remote_repo%\src\libraries\Common\tests\Tests\System\Net\Http2 /MIR

src/libraries/Common/src/System/Net/Http/Http2/CopyToCoreFx.sh → src/libraries/Common/src/System/Net/Http/Http2/CopyToRuntime.sh

@@ -3,17 +3,17 @@
 if [[ -n "$1" ]]; then
     remote_repo="$1"
 else
-    remote_repo="$COREFX_REPO"
+    remote_repo="$RUNTIME_REPO"
 fi
 
 if [[ -z "$remote_repo" ]]; then
-    echo The 'COREFX_REPO' environment variable or command line parameter is not set, aborting.
+    echo The 'RUNTIME_REPO' environment variable or command line parameter is not set, aborting.
     exit 1
 fi
 
 cd "$(dirname "$0")" || exit 1
 
-echo "COREFX_REPO: $remote_repo"
+echo "RUNTIME_REPO: $remote_repo"
 
-rsync -av --delete ./ "$remote_repo"/src/Common/src/System/Net/Http/Http2
-rsync -av --delete ./../test/Shared.Tests/Http2/ "$remote_repo"/src/Common/tests/Tests/System/Net/Http2
+rsync -av --delete ./ "$remote_repo"/src/libraries/Common/src/System/Net/Http/Http2
+rsync -av --delete ./../test/Shared.Tests/Http2/ "$remote_repo"/src/libraries/Common/tests/Tests/System/Net/Http2

src/libraries/Common/src/System/Net/Http/Http2/ReadMe.SharedCode.md

-The code in this directory is shared between CoreFx and AspNetCore. This contains HTTP/2 protocol infrastructure such as an HPACK implementation. Any changes to this dir need to be checked into both repositories.
+The code in this directory is shared between dotnet/runtime and aspnet/AspNetCore. This contains HTTP/2 protocol infrastructure such as an HPACK implementation. Any changes to this dir need to be checked into both repositories.
 
-Corefx code paths:
-- corefx\src\Common\src\System\Net\Http\Http2
-- corefx\src\Common\tests\Tests\System\Net\Http2
-AspNetCore code paths:
+dotnet/runtime code paths:
+- runtime\src\libraries\Common\src\System\Net\Http\Http2
+- runtime\src\libraries\Common\tests\Tests\System\Net\Http2
+aspnet/AspNetCore code paths:
 - AspNetCore\src\Shared\Http2
 - AspNetCore\src\Shared\test\Shared.Tests\Http2
 
 ## Copying code
-To copy code from CoreFx to AspNetCore set ASPNETCORE_REPO to the AspNetCore repo root and then run CopyToAspNetCore.cmd.
-To copy code from AspNetCore to CoreFx set COREFX_REPO to the CoreFx repo root and then run CopyToCoreFx.cmd.
+To copy code from dotnet/runtime to aspnet/AspNetCore, set ASPNETCORE_REPO to the AspNetCore repo root and then run CopyToAspNetCore.cmd.
+To copy code from aspnet/AspNetCore to dotnet/runtime, set RUNTIME_REPO to the runtime repo root and then run CopyToRuntime.cmd.
 
-## Building CoreFx code:
-- https://github.com/dotnet/corefx/blob/master/Documentation/building/windows-instructions.md
-- https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/developer-guide.md
-- Run build.cmd from the root once: `PS D:\github\corefx> .\build.cmd`
+## Building dotnet/runtime code:
+- https://github.com/dotnet/runtime/blob/master/docs/libraries/building/windows-instructions.md
+- https://github.com/dotnet/runtime/blob/master/docs/libraries/project-docs/developer-guide.md
+- Run libraries.cmd from the root once: `PS D:\github\runtime> .\libraries.cmd`
 - Build the individual projects:
-- `PS D:\github\corefx\src\Common\tests> dotnet msbuild /t:rebuild`
-- `PS D:\github\corefx\src\System.Net.Http\src> dotnet msbuild /t:rebuild`
+- `PS D:\github\dotnet\src\libraries\Common\tests> dotnet msbuild /t:rebuild`
+- `PS D:\github\dotnet\src\libraries\System.Net.Http\src> dotnet msbuild /t:rebuild`
 
-### Running CoreFx tests:
-- `PS D:\github\corefx\src\Common\tests> dotnet msbuild /t:rebuildandtest`
-- `PS D:\github\corefx\src\System.Net.Http\tests\UnitTests> dotnet msbuild /t:rebuildandtest`
+### Running dotnet/runtime tests:
+- `PS D:\github\runtime\src\libraries\Common\tests> dotnet msbuild /t:rebuildandtest`
+- `PS D:\github\runtime\src\libraries\System.Net.Http\tests\UnitTests> dotnet msbuild /t:rebuildandtest`
 
-## Building AspNetCore code:
+## Building aspnet/AspNetCore code:
 - https://github.com/aspnet/AspNetCore/blob/master/docs/BuildFromSource.md
 - Run restore in the root once: `PS D:\github\AspNetCore> .\restore.cmd`
 - Activate to use the repo local runtime: `PS D:\github\AspNetCore> . .\activate.ps1`
@@ -31,6 +31,6 @@ To copy code from AspNetCore to CoreFx set COREFX_REPO to the CoreFx repo root a
 - `(AspNetCore) PS D:\github\AspNetCore\src\Shared\test\Shared.Tests> dotnet msbuild`
 - `(AspNetCore) PS D:\github\AspNetCore\src\servers\Kestrel\core\src> dotnet msbuild`
 
-### Running AspNetCore tests:
+### Running aspnet/AspNetCore tests:
 - `(AspNetCore) PS D:\github\AspNetCore\src\Shared\test\Shared.Tests> dotnet test`
-- `(AspNetCore) PS D:\github\AspNetCore\src\servers\Kestrel\core\test> dotnet test`
\ No newline at end of file
+- `(AspNetCore) PS D:\github\AspNetCore\src\servers\Kestrel\core\test> dotnet test`

src/libraries/Common/tests/StaticTestGenerator/README.md

 # Overview
 
-This is a .NET Core utility that reflects over a corefx xunit test assembly and generates
+This is a .NET Core utility that reflects over a runtime xunit test assembly and generates
 a simple console app that invokes tests with minimal ceremony and without any reflection.
 Each test invocation is emitted as a call into the public test method, with one invocation
 generated per theory input.
@@ -9,29 +9,29 @@ generated per theory input.
 
 ## Prereqs
 
-- Build corefx from root to ensure that the testhost directory of assemblies is published, e.g. `cd d:\repos\corefx & build.cmd`.
-- Build the test assembly desired, e.g `cd src\System.Runtime\tests & dotnet msbuild`.
+- Build runtime from root to ensure that the testhost directory of assemblies is published, e.g. `cd d:\repos\runtime & .\libraries.cmd`.
+- Build the test assembly desired, e.g `cd src\libraries\System.Runtime\tests & dotnet msbuild`.
 
 ## Running the StaticTestGenerator utility
 
 From within the utility directory, run the utility with the arguments:
 - The path to the output directory into which the resulting .cs and .csproj files are written.
-- The path to a directory containing all of the corefx test host assemblies.
+- The path to a directory containing all of the runtime test host assemblies.
 - The path to the test assembly to be analyzed.
 - Any additional xunit options to be provided.  If none are provided, it defaults to the same inputs that are passed when testing inner loop on Windows.
 
 For example:
 ```
-dotnet run d:\output "d:\repos\corefx\artifacts\bin\testhost\netcoreapp-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\3.0.0" "d:\repos\corefx\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll"
+dotnet run d:\output "d:\repos\runtime\artifacts\bin\testhost\netcoreapp-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\5.0.0" "d:\repos\runtime\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll"
 ```
 This will run the tool and result in output written to the console like:
 ```
-3/27/2019 10:55:37 PM | Test assembly path    : d:\repos\corefx\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll
-3/27/2019 10:55:37 PM | Helper assemblies path: d:\repos\corefx\artifacts\bin\testhost\netcoreapp-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\3.0.0\
+3/27/2019 10:55:37 PM | Test assembly path    : d:\repos\runtime\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll
+3/27/2019 10:55:37 PM | Helper assemblies path: d:\repos\runtime\artifacts\bin\testhost\netcoreapp-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\3.0.0\
 3/27/2019 10:55:37 PM | Output path           : d:\output\System.Runtime.Tests\
-3/27/2019 10:55:37 PM | Xunit arguments       : d:\repos\corefx\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll -notrait category=nonnetcoreapptests -notrait category=nonwindowstests -notrait category=IgnoreForCI -notrait category=failing -notrait category=OuterLoop
+3/27/2019 10:55:37 PM | Xunit arguments       : d:\repos\runtime\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll -notrait category=nonnetcoreapptests -notrait category=nonwindowstests -notrait category=IgnoreForCI -notrait category=failing -notrait category=OuterLoop
 3/27/2019 10:55:37 PM |
-3/27/2019 10:55:37 PM | Loaded System.Runtime.Tests from d:\repos\corefx\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll
+3/27/2019 10:55:37 PM | Loaded System.Runtime.Tests from d:\repos\runtime\artifacts\bin\System.Runtime.Tests\netcoreapp-Windows_NT-Debug\System.Runtime.Tests.dll
 3/27/2019 10:55:37 PM | Found 5322 test methods.
 3/27/2019 10:55:38 PM | Found 3469 InlineDatas / 949 MethodDatas across 5322 test methods.
 3/27/2019 10:55:38 PM |

src/libraries/Common/tests/System/Net/Prerequisites/README.md

@@ -12,7 +12,7 @@ Note: the `config.ps1` file has been added to .gitignore to prevent it being upd
 
 ### Build the server applications 
 
-Prepare the $COREFX_NET_CLIENT_Machine as any Dev station following the instructions at https://github.com/dotnet/corefx/blob/master/Documentation/building/windows-instructions.md. Ensure that you can build and test CoreFX on this machine.
+Prepare the $COREFX_NET_CLIENT_Machine as any Dev station following the instructions at https://github.com/dotnet/runtime/blob/master/docs/libraries/building/windows-instructions.md. Ensure that you can build and test CoreFX on this machine.
 In addition, you will also need to install the _Azure development_ workload for Visual Studio 2017.
 
 From a Visual Studio command prompt:

src/libraries/Native/build-native.cmd

@@ -70,7 +70,7 @@ if "%VisualStudioVersion%"=="16.0" (
 :MissingVersion
 :: Can't find VS 2017, 2019
 echo Error: Visual Studio 2017 or 2019 required
-echo        Please see https://github.com/dotnet/corefx/tree/master/Documentation for build instructions.
+echo        Please see https://github.com/dotnet/runtime/tree/master/docs/libraries/building for build instructions.
 exit /b 1
 
 :VS2019
@@ -124,7 +124,7 @@ Make sure you selected the correct dependencies when installing Visual Studio.
 :: DIA SDK not included in Express editions
 echo Visual Studio Express does not include the DIA SDK. ^
 You need Visual Studio 2017 or 2019 (Community is free).
-echo See: https://github.com/dotnet/corefx/blob/master/Documentation/building/windows-instructions.md#required-software
+echo See: https://github.com/dotnet/runtime/blob/master/docs/libraries/building/windows-instructions.md#required-software
 exit /b 1
 
 :GenVSSolution

src/libraries/System.ComponentModel.Composition/mef_guide/README.md

@@ -6,4 +6,4 @@
 
 * It is important to recognize that MEF2 is not a new version of MEF1, but instead they serve different purposes. MEF2 is mostly suitable for web apps in order to make them more efficient. MEF1, on the other hand, uses a lot of reflection code in order to import exports, to build catalogs, and to do object instantiations but then it is more flexible in that it accepts cycles. This makes MEF1 a good option for adding dynamic extensions for long running applications. For web apps it is important to have fast response times and we deal with situations where servers might shut down, which is a good use case for MEF2.
 
-* The `System.ComponentModel.Composition` package on nuget is most widely known as MEF1 and was originally shipped for .NET Framework. `Microsoft.Composition` package later became `System.Composition` package and both are known as MEF2. For more information on MEF you can check out the [archive](https://github.com/microsoftarchive/mef) which holds old wiki documentations in it where you can find out more about differences between MEF1 and MEF2 and links to other material. The source code for MEF1 and MEF2 can be found in this repository under [`System.ComponentModel.Composition`](https://github.com/dotnet/corefx/tree/master/src/System.ComponentModel.Composition) and [`System.Composition`](https://github.com/dotnet/corefx/tree/master/src/System.Composition) respectively.
+* The `System.ComponentModel.Composition` package on nuget is most widely known as MEF1 and was originally shipped for .NET Framework. `Microsoft.Composition` package later became `System.Composition` package and both are known as MEF2. For more information on MEF you can check out the [archive](https://github.com/microsoftarchive/mef) which holds old wiki documentations in it where you can find out more about differences between MEF1 and MEF2 and links to other material. The source code for MEF1 and MEF2 can be found in this repository under [`System.ComponentModel.Composition`](https://github.com/dotnet/runtime/tree/master/src/libraries/System.ComponentModel.Composition) and [`System.Composition`](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Composition) respectively.

src/libraries/System.Data.SqlClient/tests/ManualTests/README.md

@@ -4,7 +4,7 @@ These tests require dedicated test servers, so they're designed to be run manual
 
 ## Prerequisites
 
-- CoreFX building. you need to be able to do a successful build and run the standard tests, [Unix](https://github.com/dotnet/corefx/blob/master/Documentation/building/cross-platform-testing.md) or [Windows](https://github.com/dotnet/corefx/blob/master/Documentation/building/windows-instructions.md) Use build.cmd for windows and build.sh for Linux to build CoreFX.
+- CoreFX building. you need to be able to do a successful build and run the standard tests, [Unix](https://github.com/dotnet/runtime/blob/master/docs/libraries/building/cross-platform-testing.md) or [Windows](https://github.com/dotnet/runtime/blob/master/docs/libraries/building/windows-instructions.md) Use build.cmd for windows and build.sh for Linux to build CoreFX.
 
   **N.B.** if you want to run the EFCore tests later you will need to build -allconfigurations to generate the NuGet packages, build -allconfigurations works only on windows.
 
@@ -14,7 +14,7 @@ These tests require dedicated test servers, so they're designed to be run manual
 
 - The  [Northwind Sample Database](https://msdn.microsoft.com/en-us/library/mt710790.aspx)
 
-- The [UDT Test Database](https://github.com/dotnet/corefx/tree/master/src/System.Data.SqlClient/tests/ManualTests/createUdtTestDb_corefx.sql) 
+- The [UDT Test Database](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Data.SqlClient/tests/ManualTests/createUdtTestDb_corefx.sql) 
 
 - TCP and Named Pipe [connection strings](https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx) to your instance with Northwind set as the initial catalog
 
@@ -25,7 +25,7 @@ These tests require dedicated test servers, so they're designed to be run manual
 1. set the environment variables needed for the tests you want. At the minimum you need to set
     `TEST_NP_CONN_STR` and `TEST_TCP_CONN_STR` to the connection strings. 
 
-2. Optionally you may also want to setup other environment variables to test specific optional features such as [TEST_LOCALDB_INSTALLED](https://github.com/dotnet/corefx/blob/8f7b490ca874ee2a9f11f0163412f7c95811298b/src/System.Data.SqlClient/tests/ManualTests/DataCommon/DataTestUtility.cs#L96) or [TEST_INTEGRATEDSECURITY_SETUP](https://github.com/dotnet/corefx/blob/8f7b490ca874ee2a9f11f0163412f7c95811298b/src/System.Data.SqlClient/tests/ManualTests/DataCommon/DataTestUtility.cs#L98). Other scenarios lke azure tests may need configuration so if you see those being skipped and you want to run them invesigate the skipped test code to identify how to configure it.
+2. Optionally you may also want to setup other environment variables to test specific optional features such as [TEST_LOCALDB_INSTALLED](https://github.com/dotnet/runtime/blob/be980b71efadc622b5720a36867696758e59e71c/src/libraries/System.Data.SqlClient/tests/ManualTests/DataCommon/DataTestUtility.cs#L123) or [TEST_INTEGRATEDSECURITY_SETUP](https://github.com/dotnet/runtime/blob/be980b71efadc622b5720a36867696758e59e71c/src/libraries/System.Data.SqlClient/tests/ManualTests/DataCommon/DataTestUtility.cs#L125). Other scenarios lke azure tests may need configuration so if you see those being skipped and you want to run them invesigate the skipped test code to identify how to configure it.
 
 3. run `dotnet msbuild .\src\System.Data.SqlClient\tests\ManualTests\System.Data.SqlClient.ManualTesting.Tests.csproj /t:Rebuild` to build the debug version with all the assertions and run the tests.
 
@@ -36,4 +36,4 @@ These tests require dedicated test servers, so they're designed to be run manual
 ## Running A Specific Test
 
 Once you have all tests running you may need to debug a single failing test. To do this navigate into the manual tests project directory `cd src\System.Data.SqlClient\tests\ManualTests` then run dotnet msbuild and specify the name of the test you want to execute, like this:
- `dotnet msbuild /t:RebuildAndTest /p:XunitMethodName=System.Data.SqlClient.ManualTesting.Tests.DDDataTypesTest.MaxTypesTest`
\ No newline at end of file
+ `dotnet msbuild /t:RebuildAndTest /p:XunitMethodName=System.Data.SqlClient.ManualTesting.Tests.DDDataTypesTest.MaxTypesTest`

src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md

@@ -17,7 +17,7 @@ External dependency Activity Id is passed along with the request, so the depende
 
 Activities may be created and started/stopped by platform code or frameworks; applications need to be notified about activities events and need to have access to current activity being processed.
 Therefore code which creates activity also writes corresponding event to `DiagnosticSource`:
-- DO - create new `DiagnosticListener` for specific Activity type to allow filtering by activity. E.g Incoming and Outgoing Http Requests should be different DiagnosticListeners. Follow [DiagnosticSource User Guide](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md) to pick a name.
+- DO - create new `DiagnosticListener` for specific Activity type to allow filtering by activity. E.g Incoming and Outgoing Http Requests should be different DiagnosticListeners. Follow [DiagnosticSource User Guide](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md) to pick a name.
 - DO - Guard Activity creation and start with call to `DiagnosticSource.IsEnabled` to avoid creating activities when no-one is listening to them and to enable event name-based filtering or sampling.
 - DO - Use `DiagnosticSource.StartActivity(Activity)` and `DiagnosticSource.StopActivity(Activity)` methods instead of Activity methods to ensure Activity events are always written to `DiagnosticSource`.
 - DO - pass any necessary context to `DiagnosticListener`, so your application may enrich Activity. For example, in the case of an incoming HTTP request, the application needs an instance of `HttpContext` in order to add custom tags (method, path, user-agent, etc.)
@@ -108,7 +108,7 @@ Note that different DiagnosticSources should be used for incoming and outgoing H
 
 ## Listening to Activity Events
 An application may listen to activity events and log them. It can access `Activity.Current` to get information about the current activity.
-This follows normal [DiagnosticListener conventions](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md).
+This follows normal [DiagnosticListener conventions](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md).
 
 An application may also add tags and baggage to the current activity when processing an Activity start callback.
 Note that in the [Incoming Request Sample](#starting-and-stopping-activity), we pass `HttpContext` to DiagnosticSource, so that the application has access to the request properties in order to enrich the current activity.

src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md

@@ -15,7 +15,7 @@ instrumenting code.
 In addition to `DiagnosticSource`, there are two other logging systems provided by Microsoft:
 
 1. `EventSource` [docs](https://msdn.microsoft.com/en-us/library/system.diagnostics.tracing.eventsource(v=vs.110).aspx)
-   and [src](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs).
+   and [src](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs).
    `EventSource` has been available since V4.5 of the .NET Runtime and is what is used
    to instrument the runtime itself. It is designed to be fast and to be strongly
    typed (payloads are typed, named properties), and to interface with OS logging
@@ -374,7 +374,7 @@ Note that using reflection is relatively expensive. However, using reflection is
 option if the payloads were generated using anonymous types. You can reduce this overhead by
 making fast, specialized property fetchers either using `PropertyInfo.CreateDelegate` or
 `ReflectEmit`, but that is beyond the scope of this document.
-(See the [PropertySpec](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L784)
+(See the [PropertySpec](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L784)
 class used in the `DiagnosticSourceEventSource` for an example of a fast, delegate-based property fetcher.)
 
 #### Filtering
@@ -453,5 +453,5 @@ subscribe to any `DiagnosticListener` as well as pluck off particular data items
 Thus code that is using `System.Diagnostics.Tracing.EventListener` or ETW can get at
 any information logged with `DiagnosticSource`.
 
-See [DiagnosticSourceEventSource](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs)
+See [DiagnosticSourceEventSource](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs)
 for more information on how to use it.

src/libraries/System.Net.Http/src/HttpDiagnosticsGuide.md

 # HttpClient Diagnostic  Instrumentation Users Guide
 
-This document describes `HttpClientHandler` instrumentation with [`DiagnosticSource`](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md).
+This document describes `HttpClientHandler` instrumentation with [`DiagnosticSource`](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md).
 
 # Overview
 Applications typically log outgoing HTTP requests. Usually, it's done with `DelegatingHandler` implementation that logs every request. However, in an existing system, it may require extensive code changes, since `DelegatingHandler` needs to be added to the `HttpClient` pipeline every time when a new client is created.
 `DiagnosticListener` instrumentation allows to enable outgoing request tracing with a few lines of code; it also provides the context necessary to correlate logs.
 
-Context is represented as `System.Diagnostics.Activity` class. `Activity` may be started as a child of another `Activity`, and the whole operation is represented with a tree of Activities. You can find more details in the [Activity User Guide](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md).
+Context is represented as `System.Diagnostics.Activity` class. `Activity` may be started as a child of another `Activity`, and the whole operation is represented with a tree of Activities. You can find more details in the [Activity User Guide](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md).
 
 `Activity` carries useful properties for logging such as `Id`, `Tags`, `Baggage`, start time and parent information. 
 
@@ -17,7 +17,7 @@ Instrumentation adds context into the request headers:
  * *Request-Id* header with `Activity.Id` value
  * *Correlation-Context* header with `Activity.Baggage` key-value pair list in `k1=v1, k2=v2` format
  
-See [HTTP Protocol proposal](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/HttpCorrelationProtocol.md) for more details.
+See [HTTP Protocol proposal](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/HttpCorrelationProtocol.md) for more details.
 
 ## Subscription
 Instrumentation is off by default. To enable it, consumer firstly needs to subscribe to a `DiagnosticListener` called *HttpHandlerDiagnosticListener*. 

src/libraries/System.Net.Http/tests/StressTests/HttpStress/Readme.md

@@ -16,32 +16,32 @@ To get the full list of available parameters:
 $ dotnet run -- -help
 ```
 
-### Running with local corefx builds
+### Running with local runtime builds
 
 Note that the stress suite will test the sdk build available in the available,
-that is to say it will not necessarily test the implementation of the local corefx repo.
-To achieve this, you will need to point your environment to the [`testhost` build of corefx](https://github.com/dotnet/coreclr/blob/master/Documentation/building/testing-with-corefx.md).
+that is to say it will not necessarily test the implementation of the local runtime repo.
+To achieve this, you will need to point your environment to the [`testhost` build](https://github.com/dotnet/runtime/blob/master/docs/coreclr/building/testing-with-corefx.md).
 
 Using powershell on windows:
 
 ```powershell
-# Build corefx from source
-PS> .\build.sh -c Release
+# Build runtime libraries from source
+PS> .\libraries.sh -c Release
 # Load the testhost sdk in the current environment, must match build configuration
-PS> . .\src\System.Net.Http\tests\StressTests\HttpStress\load-corefx-testhost.ps1 -c Release
+PS> . .\src\libraries\System.Net.Http\tests\StressTests\HttpStress\load-corefx-testhost.ps1 -c Release
 # run the stress suite with the new bits
-PS> cd .\src\System.Net.Http\tests\StressTests\HttpStress ; dotnet run -c Release -- <stress args>
+PS> cd .\src\libraries\System.Net.Http\tests\StressTests\HttpStress ; dotnet run -c Release -- <stress args>
 ```
 
 Equivalently using bash on linux:
 
 ```bash
-# Build corefx from source
-$ ./build.sh -c Release
+# Build runtime libraries from source
+$ ./libraries.sh -c Release
 # Load the testhost sdk in the current environment, must match build configuration
-$ source src/System.Net.Http/tests/StressTests/HttpStress/load-corefx-testhost.sh -c Release
+$ source src/libraries/System.Net.Http/tests/StressTests/HttpStress/load-corefx-testhost.sh -c Release
 # run the stress suite with the new bits
-$ cd src/System.Net.Http/tests/StressTests/HttpStress && dotnet run -- <stress args>
+$ cd src/libraries/System.Net.Http/tests/StressTests/HttpStress && dotnet run -- <stress args>
 ```
 
 ### Running with docker
@@ -49,7 +49,7 @@ $ cd src/System.Net.Http/tests/StressTests/HttpStress && dotnet run -- <stress a
 To run the stress suite in docker:
 
 ```bash
-$ cd src/System.Net.Http/tests/StressTests/HttpStress
+$ cd src/libraries/System.Net.Http/tests/StressTests/HttpStress
 $ docker build -t httpstress .
 $ docker run --rm httpstress
 ```
@@ -65,18 +65,18 @@ $ docker build -t httpstress \
 
 This should work with any base image with a dotnet sdk supporting `netcoreapp3.0`.
 
-#### Using corefx bits
+#### Using runtime bits
 
-To containerize httpstress using current corefx source code, from the root of the corefx repo do:
+To containerize httpstress using current runtime source code, from the root of the runtime repo do:
 ```bash
 $ docker build -t sdk-corefx-current \
     --build-arg BUILD_CONFIGURATION=Debug \
-    -f src/System.Net.Http/tests/StressTests/HttpStress/corefx.Dockerfile \
+    -f src/libraries/System.Net.Http/tests/StressTests/HttpStress/corefx.Dockerfile \
     .
 ```
 Then as before build the stress suite using the image we just built as our base image:
 ```bash
-$ cd src/System.Net.Http/tests/StressTests/HttpStress/
+$ cd src/libraries/System.Net.Http/tests/StressTests/HttpStress/
 $ docker build -t httpstress \
     --build-arg SDK_BASE_IMAGE=sdk-corefx-current \
     .

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

 # System.Private.CoreLib Shared Sources
 
-This directory contains the shared sources for System.Private.CoreLib. These are shared between [mono/mono](https://github.com/mono/mono/tree/master/netcore/System.Private.CoreLib/shared), [dotnet/coreclr](https://github.com/dotnet/coreclr/tree/master/src/System.Private.CoreLib/shared) and [dotnet/corefx](https://github.com/dotnet/corefx/tree/master/src/Common/src/CoreLib).
-
-The sources are synchronized with a mirroring tool that watches for new commits on either side and creates new pull requests (as @dotnet-bot) in the other repository.
-
-## Conventions
-
-Code in the shared directory should have no code specific to CoreCLR, CoreRT or CoreFX. Parts of classes that need to have different implementations on different runtimes should use partial classes and *.CoreCLR.cs/*.CoreFX.cs files in the non shared portion. Code that is different based on platform (Windows/Unix) is fine to leave in the shared portion. Remember to follow the [style guidelines](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md).
-
-## Getting clean CI and merging the mirror PRs
-
-Once the mirror PR is created there is a chance that the new code will require changes to get a clean CI. Any changes can be added to the PR by checking out the PR branch and adding new commits. Please follow the following guidelines for modifying these PRs.
-
- - **DO NOT** modify the commits made by @dotnet-bot in any way.
- - **TRY** to only make changes outside of shared.
-   - Changes made in the shared folder in additional commits will get mirrored properly if the mirror PR is merged with a **REBASE**
- - **ALWAYS** Merge the mirror PR with the **REBASE** option.
-   - Using one of the other options will cause the mirror to miss commits
+This directory contains the shared sources for System.Private.CoreLib. It represents the majority of the CoreLib implementation.  Each flavor of the runtime (e.g. coreclr, mono) provides a few additional files as part of its build of CoreLib to complement this directory's contents.

src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/SuppressGCTransitionAttribute.cs

@@ -33,7 +33,7 @@ namespace System.Runtime.InteropServices
     /// of the unmanaged function. However, avoiding this transition removes some of the guarantees the runtime
     /// provides through a normal P/Invoke. When exiting the managed runtime to enter an unmanaged function the
     /// GC must transition from Cooperative mode into Preemptive mode. Full details on these modes can be found at
-    /// https://github.com/dotnet/coreclr/blob/master/Documentation/coding-guidelines/clr-code-guide.md#2.1.8.
+    /// https://github.com/dotnet/runtime/blob/master/docs/coreclr/coding-guidelines/clr-code-guide.md#2.1.8.
     /// Suppressing the GC transition is an advanced scenario and should not be done without fully understanding
     /// potential consequences.
     ///
@@ -62,4 +62,4 @@ public SuppressGCTransitionAttribute()
         {
         }
     }
-}
\ No newline at end of file
+}

src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs

@@ -466,7 +466,7 @@ private void VerifyIsAlive()
         ///
         /// The property is stored in an AsyncLocal<AssemblyLoadContext>. This means the setting can be unique for every async or thread in the process.
         ///
-        /// For more details see https://github.com/dotnet/coreclr/blob/master/Documentation/design-docs/AssemblyLoadContext.ContextualReflection.md
+        /// For more details see https://github.com/dotnet/runtime/blob/master/docs/coreclr/design-docs/AssemblyLoadContext.ContextualReflection.md
         /// </remarks>
         public static AssemblyLoadContext? CurrentContextualReflectionContext => s_asyncLocalCurrent?.Value;
 

src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs

@@ -135,7 +135,7 @@ internal static void RunInternal(ExecutionContext? executionContext, ContextCall
         {
             // Note: ExecutionContext.RunInternal is an extremely hot function and used by every await, ThreadPool execution, etc.
             // Note: Manual enregistering may be addressed by "Exception Handling Write Through Optimization"
-            //       https://github.com/dotnet/coreclr/blob/master/Documentation/design-docs/eh-writethru.md
+            //       https://github.com/dotnet/runtime/blob/master/docs/coreclr/design-docs/eh-writethru.md
 
             // Enregister variables with 0 post-fix so they can be used in registers without EH forcing them to stack
             // Capture references to Thread Contexts
@@ -205,7 +205,7 @@ internal static void RunInternal<TState>(ExecutionContext? executionContext, Con
         {
             // Note: ExecutionContext.RunInternal is an extremely hot function and used by every await, ThreadPool execution, etc.
             // Note: Manual enregistering may be addressed by "Exception Handling Write Through Optimization"
-            //       https://github.com/dotnet/coreclr/blob/master/Documentation/design-docs/eh-writethru.md
+            //       https://github.com/dotnet/runtime/blob/master/docs/coreclr/design-docs/eh-writethru.md
 
             // Enregister variables with 0 post-fix so they can be used in registers without EH forcing them to stack
             // Capture references to Thread Contexts

src/libraries/System.Reflection.Metadata/tests/Resources/README.md

@@ -12,4 +12,4 @@ The same-named source files include the appropriate command to use to build the
 
 ## License
 
-Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/corefx/blob/master/LICENSE) at the root of the repo for more information.
\ No newline at end of file
+Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/runtime/blob/master/LICENSE.TXT) at the root of the repo for more information.

src/libraries/System.Runtime/tests/TestModule/README.md

@@ -8,4 +8,4 @@ You can build this project with msbuild.
 
 ## License
 
-Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/corefx/blob/master/LICENSE) at the root of the repo for more information.
\ No newline at end of file
+Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/runtime/blob/master/LICENSE.TXT) at the root of the repo for more information.

src/libraries/System.Text.Encodings.Web/tools/updating-encodings.md

@@ -26,7 +26,7 @@ dotnet run -- "path_to_UnicodeData.txt" ../../src/System/Text/Unicode/UnicodeHel
 dotnet run -- "path_to_Blocks.txt" ../../src/System/Text/Unicode/UnicodeRanges.generated.cs ../../tests/UnicodeRangesTests.generated.cs
 ```
 
-4. Update the __ref__ APIs to reflect any new `UnicodeRanges` static properties which were added in the previous step, otherwise the unit test project will not be able to reference them. See https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/updating-ref-source.md for instructions on how to update the reference assemblies.
+4. Update the __ref__ APIs to reflect any new `UnicodeRanges` static properties which were added in the previous step, otherwise the unit test project will not be able to reference them. See https://github.com/dotnet/runtime/blob/master/docs/libraries/coding-guidelines/updating-ref-source.md for instructions on how to update the reference assemblies.
 
 5. Update the __src/System.Text.Encodings.Web/tests/System.Text.Encodings.Web.Tests.csproj__ file to reference the new file that you dropped into the __src/Common/tests/data__ folder in the first step above. Open the .csproj file in a text editor, and replace both the `<EmbeddedResource>` and the `<LogicalName>` elements at the end of the document to reference the new file name.
 

src/libraries/System.Text.Json/porting_guide/README.md

@@ -4,7 +4,7 @@
 
 * The `System.Text.Json` APIs that are included in .NET Core 3.0 are designed primarily for performance critical scenarios and hence emphasize runtime performance and reducing allocations over high usability and convenience. Furthermore, the in-box JSON stack does not aim to provide feature parity with `Newtonsoft.Json`, especially since it is in its infancy. That said, we still want to make it easier for those whose needs can be fulfilled by the new APIs and those who are looking for better performance. This guide captures some of the common pitfalls and programming patterns that are useful to note when trying to use the new in-box APIs.
   - Please help contribute to this porting guide to help others onboard to the new APIs.
-  - For an overview on the objectives, constraints, and design requirements of the new APIs, please see the [roadmap](https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/roadmap/README.md).
+  - For an overview on the objectives, constraints, and design requirements of the new APIs, please see the [roadmap](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Text.Json/roadmap/README.md).
   - If you have any feedback or feature requests, feel free to submit issues: https://github.com/dotnet/corefx/issues
 
 ## Common Pitfalls, Patterns, and Tips
@@ -170,4 +170,4 @@ public static string ReadAsString(this ref Utf8JsonReader reader)
 
     return reader.GetString();
 }
-```
\ No newline at end of file
+```

src/libraries/System.Utf8String.Experimental/README.md

@@ -20,7 +20,7 @@ This can occur if the NuGet client attempts to install a newer version of the pa
 install-package System.Utf8String.Experimental -prerelease -source https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json -version 3.0.0-preview6.19223.2
 ```
 
-Not all of the APIs are hooked up yet, but we have some preliminary APIs that allow experimentation with the feature, including basic creation and inspection of `Utf8String` instances, wrapping a `ReadOnlySpan<byte>` or a `ReadOnlyMemory<byte>` around a `Utf8String` instance, and passing a `Utf8String` instance through `HttpClient`. Full list of APIs available at https://github.com/dotnet/corefx/blob/master/src/System.Utf8String.Experimental/ref/System.Utf8String.cs.
+Not all of the APIs are hooked up yet, but we have some preliminary APIs that allow experimentation with the feature, including basic creation and inspection of `Utf8String` instances, wrapping a `ReadOnlySpan<byte>` or a `ReadOnlyMemory<byte>` around a `Utf8String` instance, and passing a `Utf8String` instance through `HttpClient`. Full list of APIs available at https://github.com/dotnet/runtime/blob/master/src/libraries/System.Utf8String.Experimental/ref/System.Utf8String.cs.
 
 Certain language features also work as expected.