remove corefx from md (#105275)

docs/coding-guidelines/api-guidelines/nullability.md

@@ -67,7 +67,7 @@ However, for existing virtual APIs that do not have any such strong guarantee do
 4. How common is it in the case of (3) for such invocations to then dereference the result rather than passing it off to something else that accepts a `T?`?
 
 `Object.ToString` is arguably the most extreme case.  Answering the above questions:
-1. It is fairly easy in any reasonably-sized code base to find cases, intentional or otherwise, where `ToString` returns `null` in some cases (we've found examples in dotnet/corefx, dotnet/roslyn, NuGet/NuGet.Client, dotnet/aspnetcore, and so on).  One of the most prevalent conditions for this are types that just return the value in a string field which may contain its default value of `null`, and in particular for structs where a ctor may not have even had a chance to run and validate an input.  Guidance in the docs suggests that `ToString` shouldn't return `null` or `string.Empty`, but even the docs don't follow its own guidance.
+1. It is fairly easy in any reasonably-sized code base to find cases, intentional or otherwise, where `ToString` returns `null` in some cases (we've found examples in dotnet/runtime, dotnet/roslyn, NuGet/NuGet.Client, dotnet/aspnetcore, and so on).  One of the most prevalent conditions for this are types that just return the value in a string field which may contain its default value of `null`, and in particular for structs where a ctor may not have even had a chance to run and validate an input.  Guidance in the docs suggests that `ToString` shouldn't return `null` or `string.Empty`, but even the docs don't follow its own guidance.
 2. Thousands upon thousands of types we don't control override this method today.
 3. It's common for helper routines to invoke via the base `object.ToString`, but many `ToString` uses are actually on derived types.  This is particularly true when working in a code base that both defines a type and consumes its `ToString`.
 4. Based on examination of several large code bases, we believe it to be relatively rare that the result of an `Object.ToString` call (made on the base) to be directly dereferenced.  It's much more common to pass it to another method that accepts `string?`, such as `String.Concat`, `String.Format`, `Console.WriteLine`, logging utilities, and so on.  And while we advocate that `ToString` results shouldn't be assumed to be in a particular machine-readable format and parsed, it's certainly the case that code bases do, such as using `Substring` on the result, but in such cases, the caller needs to understand the format of what's being rendered, which generally means they're working with a derived type rather than calling through the base `Object.ToString`.

docs/design/coreclr/jit/JitOptimizerTodoAssessment.md

@@ -49,7 +49,7 @@ the code quality improvements, though most have issues associated with them.
 We may well be able to find some additional benchmarks or real-world-code with some looking,
 though it may be the case that current performance-sensitive code avoids structs.
 
-There's also work going on in corefx to use `Span<T>` more broadly.  We should
+There's also work going on to use `Span<T>` more broadly.  We should
 make sure we are expanding our span benchmarks appropriately to track and
 respond to any particular issues that come out of that work.
 

docs/design/coreclr/jit/object-stack-allocation.md

@@ -83,7 +83,7 @@ with version reseliency.
 **Pros:**
 * ILLInk can afford to spend more time for escape analysis.
 * For self-contained apps, ILLink has access to all of application's code and can do full interprocedural analysis.
-* ILLink is already a part of System.Private.CoreLib and CoreFX build toolchain so the assemblies built there can benefit
+* ILLink is already a part of System.Private.CoreLib and core libraries build toolchain so the assemblies built there can benefit
 from this.
 
 **Cons:**

docs/design/features/AssemblyLoadContext.ContextualReflection.md

@@ -22,7 +22,7 @@ Using `pluginDependency` to determine the `AssemblyLoadContext` used for loading
 ### Failing Scenarios
 #### Xunit story
 
-We have been working on building a test harness in Xunit for running the CoreFX test suite inside `AssemblyLoadContext`s (each test case in its own context).  This has proven to be somewhat difficult due to Xunit being a very reflection heavy codebase with tons of instances of types, assemblies, etc. being converted to strings and then fed through `Activator`.  One of the main learnings is that it is not always obvious what will stay inside the “bounds” of an `AssemblyLoadContext` and what won’t.  The basic rule of thumb is that any `Assembly.Load()` will result in the assembly being loaded onto the `AssemblyLoadContext` of the calling code, so if code loaded by an ALC calls `Assembly.Load(...)`, the resulting assembly will be within the “bounds” of the ALC.  This unfortunately breaks down in some cases, specifically when code calls `Activator` which lives in `System.Private.CoreLib` which is always shared.
+We have been working on building a test harness in Xunit for running the core libraries test suite inside `AssemblyLoadContext`s (each test case in its own context).  This has proven to be somewhat difficult due to Xunit being a very reflection heavy codebase with tons of instances of types, assemblies, etc. being converted to strings and then fed through `Activator`.  One of the main learnings is that it is not always obvious what will stay inside the “bounds” of an `AssemblyLoadContext` and what won’t.  The basic rule of thumb is that any `Assembly.Load()` will result in the assembly being loaded onto the `AssemblyLoadContext` of the calling code, so if code loaded by an ALC calls `Assembly.Load(...)`, the resulting assembly will be within the “bounds” of the ALC.  This unfortunately breaks down in some cases, specifically when code calls `Activator` which lives in `System.Private.CoreLib` which is always shared.
 
 #### System.Xaml
 This problem also manifests when using an `Object` deserialization framework which allows specifying assembly qualified type names.

docs/design/features/arm64-intrinsics.md

@@ -263,9 +263,6 @@ To facilitate incremental progress, initial intrinsic API for a given `static cl
 
 As intrinsic support is added test coverage must be extended to provide basic testing.
 
-Tests should be added as soon as practical.  CoreCLR Implementation and CoreFX API will need to be merged before tests
-can be merged.
-
 ## LSRA changes to allocate contiguous register ranges
 
 Some ARM64 instructions will require allocation of contiguous blocks of registers.  These are likely limited to load and

docs/design/features/hw-intrinsics.md

@@ -10,11 +10,7 @@ There is a design document for the Arm64 intrinsics: https://github.com/dotnet/r
 
 ## Overview
 
-The reference assemblies for the hardware intrinsics live in corefx, but all of the implementation is in the coreclr repo:
-
-* The C# implementation lives in coreclr/System.Private.CoreLib/shared/System/Runtime/Intrinsics. These are little more than skeleton methods that are only compiled if needed for indirect invocation.
-
-  * Note that they are mirrored to other repositories, including corefx, corert and mono.
+* The C# implementation lives in src/libraries/System.Private.CoreLib/shared/System/Runtime/Intrinsics. These are little more than skeleton methods that are only compiled if needed for indirect invocation.
 
 ## C# Implementation
 

docs/project/glossary.md

@@ -14,13 +14,13 @@ terminology.
 | AOT | Ahead-of-time compiler. Converts the MSIL bytecode to native machine code for a specific target CPU architecture. |
 | BBT | Microsoft internal early version of C/C++ PGO. See https://www.microsoft.com/windows/cse/bit_projects.mspx. |
 | BOTR | Book Of The Runtime. |
-| BCL | Base Class Library. A set of `System.*` (and to a limited extent `Microsoft.*`) libraries that make up the lower layer of the .NET library stack. |
+| BCL | Base Class Library. A set of `System.*` (and to a limited extent `Microsoft.*`) libraries that make up the lower layer of the .NET library stack. See CoreFX. |
 | CIL | Common Intermediate Language. Equivalent to IL, also equivalent to [MSIL](https://learn.microsoft.com/dotnet/standard/managed-execution-process#compiling-to-msil). |
 | CLI | Command Line Interface, or Common Language Infastructure. |
 | CLR | [Common Language Runtime](https://learn.microsoft.com/dotnet/standard/clr). |
 | COMPlus | An early name for the .NET platform, back when it was envisioned as a successor to the COM platform (hence, "COM+"). Used in various places in the CLR infrastructure, most prominently as a common prefix for the names of internal configuration settings. Note that this is different from the product that eventually ended up being named [COM+](https://msdn.microsoft.com/library/windows/desktop/ms685978.aspx). |
 | COR | [Common Object Runtime](http://www.danielmoth.com/Blog/mscorlibdll.aspx). The name of .NET before it was named .NET. |
-| CoreFX | Core Framework. Original project name for open source and cross-platform version of [.NET runtime libraries](https://github.com/dotnet/runtime/tree/main/src/libraries) |
+| CoreFX | Core Framework. Original project name for open source and cross-platform version of [.NET runtime libraries](https://github.com/dotnet/runtime/tree/main/src/libraries). Where we want to distinguish the foundational .NET libraries - those in the dotnet/runtime repo - instead of CoreFX or BCL we call them the core libraries. |
 | DAC | Data Access Component. An abstraction layer over the internal structures in the runtime. |
 | EE | [Execution Engine](https://learn.microsoft.com/dotnet/standard/managed-execution-process#running_code). |
 | GC | [Garbage Collector](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/garbage-collection.md). |
@@ -285,8 +285,8 @@ and enabling support for running WPF on .NET Core (Windows Only).
 ## Engineering system
 
 * **Helix**. It's a massively-parallel, general-purpose job processing and
-  result aggregation system running in the cloud. The work items that corefx
-  sends to Helix are [xunit][xunit] tests. Test results are shown through the
+  result aggregation system running in the cloud. The work items that we
+  send to Helix are [xunit][xunit] tests. Test results are shown through the
   [*Mission Control* reporting site][mc.dot.net]; to go to the test results in a
   PR from Azure DevOps, you can click on the *Send to Helix* step in the build,
   and the logs will have the URL.

docs/project/issue-guide.md

@@ -1,14 +1,14 @@
 Issue Guide
 ===========
 
-This page outlines how the CoreFx team thinks about and handles issues.  For us, issues on GitHub represent actionable work that should be done at some future point.  It may be as simple as a small product or test bug or as large as the work tracking the design of a new feature.  However, it should be work that falls under the charter of CoreFx, which is a collection of foundational libraries that make up the .NET Core development stack.  We will keep issues open even if the CoreFx team internally has no plans to address them in an upcoming release, as long as we consider the issue to fall under our purview.
+This page outlines how the team thinks about and handles issues in this repo.  For us, issues on GitHub represent actionable work that should be done at some future point.  It may be as simple as a small product or test bug or as large as the work tracking the design of a new feature.  However, it should be work that falls under the charter of the team.  We will keep issues open even if the team internally has no plans to address them in an upcoming release, as long as we consider the issue to fall under our purview and something we would potentially take a change for.
 
 ### When we close issues
 As noted above, we don't close issues just because we don't plan to address them in an upcoming release.  So why do we close issues?  There are few major reasons:
 
-1. Issues unrelated to CoreFx.  When possible, we'll try to find a better home for the issue and point you to it.
+1. Issues unrelated to code in this repo.  When possible, we'll try to find a better home for the issue and point you to it.
 2. Cross cutting work better suited for another team.  Sometimes the line between the framework, languages and runtime blurs.  For some issues, we may feel that the work is better suited for the runtime team, language team or other partner.  In these cases, we'll close the issue and open it with the partner team.  If they end up not deciding to take on the issue, we can reconsider it here.
-3. Nebulous and Large open issues.  Large open issues are sometimes better suited for [User Voice](http://visualstudio.uservoice.com/forums/121579-visual-studio/category/31481--net), especially when the work will cross the boundaries of the framework, language and runtime.  A good example of this is the SIMD support we recently added to CoreFx.  This started as a [User Voice request](https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2212443-c-and-simd), and eventually turned into work for both the core libraries and runtime.
+3. Nebulous and Large open issues.  Large open issues are sometimes better suited for [User Voice](http://visualstudio.uservoice.com/forums/121579-visual-studio/category/31481--net), especially when the work will cross the boundaries of the framework, language and runtime.  A good example of this is the SIMD support we recently added to the core libraries.  This started as a [User Voice request](https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2212443-c-and-simd), and eventually turned into work for both the core libraries and runtime.
 
 Sometimes after debate, we'll decide an issue isn't a good fit for the .NET runtime codebase.  In that case, we'll also close it.  Because of this, we ask that you don't start working on an issue until it's tagged with [help wanted](https://github.com/dotnet/runtime/labels/help%20wanted) or [api-approved](https://github.com/dotnet/runtime/labels/api-approved).  Both you and the team will be unhappy if you spend time and effort working on a change we'll ultimately be unable to take. We try to avoid that.
 
@@ -78,8 +78,8 @@ Feel free to use other labels if it helps your triage efforts (e.g. **needs more
 
 1. Each PR has exactly one **area-\*** label
     * Movitation: Area owners will get email notification about new issue in their area.
-1. PR has **Assignee** set to author of the PR, if it is non-CoreFX engineer, then area owners are co-assignees
-    * Motivation #1: Area owners are responsible to do code reviews for PRs from external contributors. CoreFX engineers know how to get code reviews from others.
+1. PR has **Assignee** set to author of the PR, if it is engineer that does not work in this repo, then area owners are co-assignees
+    * Motivation #1: Area owners are responsible to do code reviews for PRs from external contributors. Committers know how to get code reviews from others.
     * Motivation #2: Assignees will get notifications for anything happening on the PR.
 1. [Optional] Set milestone according to the branch the PR is against (main = 6.0, release/5.0 = 5.0)
     * Motivation: Easier to track and audit where which fix ended up and if it needs to be ported into another branch (hence reflecting branch the specific PR ended up and not the abstract issue).

docs/project/jit-testing.md

@@ -112,7 +112,7 @@ Not yet clear what porting this entails.
 ### Leverage peer repo test suites.
 
 We should be able to directly leverage tests provided in peer repo suites, once
-they can run on top of CoreCLR. In particular CoreFx and Roslyn test cases
+they can run on top of CoreCLR. In particular libraries and Roslyn test cases
 could be good initial targets.
 
 Note LLILC is currently working through the remaining issues that prevent it

docs/workflow/debugging/libraries/unix-instructions.md

@@ -1,7 +1,7 @@
-Debugging CoreFX on Unix
-==========================
+Debugging core .NET libraries on Unix
+=====================================
 
-CoreFX can be debugged on unix using both lldb and visual studio code
+.NET can be debugged on unix using both lldb and Visual Studio Code.
 
 ## Using lldb and SOS
 

docs/workflow/debugging/libraries/windows-instructions.md

@@ -1,5 +1,5 @@
-Debugging CoreFX on Windows
-==========================
+Debugging core .NET libraries on Windows
+========================================
 
 You can Debug .NET via Visual Studio or WinDBG.
 
@@ -37,11 +37,11 @@ For example: `src\System.Net.Sockets\tests\Functional\System.Net.Sockets.Tests.c
 
 * Execute the test
 
-Assuming that your repo is at `C:\corefx`:
+Assuming that your repo is at `C:\root`:
 
 ```
-cd C:\corefx\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0
-C:\corefx\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0\CoreRun.exe xunit.console.dll System.Net.Sockets.Tests.dll -xml testResults.xml -notrait category=nonwindowstests -notrait category=OuterLoop -notrait category=failing
+cd C:\root\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0
+C:\root\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0\CoreRun.exe xunit.console.dll System.Net.Sockets.Tests.dll -xml testResults.xml -notrait category=nonwindowstests -notrait category=OuterLoop -notrait category=failing
 ```
 
 * If the test crashes or encounters a `Debugger.Launch()` method call, WinDBG will automatically start and attach to the `CoreRun.exe` process
@@ -52,7 +52,7 @@ The following commands will properly configure the debugging extension and fix s
 .symfix
 .srcfix
 .reload
-!load C:\corefx\packages\runtime.win7-x64.Microsoft.NETCore.Runtime.CoreCLR\<version>\tools\sos
+!load C:\root\packages\runtime.win7-x64.Microsoft.NETCore.Runtime.CoreCLR\<version>\tools\sos
 ```
 
 _Important_: Pass in the correct path to your SOS extension discovered during the Prerequisites, step 2.
@@ -137,7 +137,7 @@ Logs are going to be placed in %SYSTEMDRIVE%\sockets.etl.
 
 ### Built-in EventSource tracing
 
-The following EventSources are built-in to CoreFX. The ones that are not marked as [__TestCode__] can be enabled in production scenarios for log collection.
+The following EventSources are built-in to the .NET platform. The ones that are not marked as [__TestCode__] can be enabled in production scenarios for log collection.
 
 #### Global
 * `*System.Diagnostics.Eventing.FrameworkEventSource {8E9F5090-2D75-4d03-8A81-E5AFBF85DAF1}`: Global EventSource used by multiple namespaces.