Skip to content

Commit b252fa5

Browse files
authored
remove corefx from md (#105275)
1 parent c881a7a commit b252fa5

File tree

11 files changed

+25
-32
lines changed

11 files changed

+25
-32
lines changed

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -67,7 +67,7 @@ However, for existing virtual APIs that do not have any such strong guarantee do
6767
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?`?
6868

6969
`Object.ToString` is arguably the most extreme case. Answering the above questions:
70-
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.
70+
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.
7171
2. Thousands upon thousands of types we don't control override this method today.
7272
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`.
7373
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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ the code quality improvements, though most have issues associated with them.
4949
We may well be able to find some additional benchmarks or real-world-code with some looking,
5050
though it may be the case that current performance-sensitive code avoids structs.
5151

52-
There's also work going on in corefx to use `Span<T>` more broadly. We should
52+
There's also work going on to use `Span<T>` more broadly. We should
5353
make sure we are expanding our span benchmarks appropriately to track and
5454
respond to any particular issues that come out of that work.
5555

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -83,7 +83,7 @@ with version reseliency.
8383
**Pros:**
8484
* ILLInk can afford to spend more time for escape analysis.
8585
* For self-contained apps, ILLink has access to all of application's code and can do full interprocedural analysis.
86-
* ILLink is already a part of System.Private.CoreLib and CoreFX build toolchain so the assemblies built there can benefit
86+
* ILLink is already a part of System.Private.CoreLib and core libraries build toolchain so the assemblies built there can benefit
8787
from this.
8888

8989
**Cons:**

docs/design/features/AssemblyLoadContext.ContextualReflection.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ Using `pluginDependency` to determine the `AssemblyLoadContext` used for loading
2222
### Failing Scenarios
2323
#### Xunit story
2424

25-
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.
25+
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.
2626

2727
#### System.Xaml
2828
This problem also manifests when using an `Object` deserialization framework which allows specifying assembly qualified type names.

docs/design/features/arm64-intrinsics.md

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -263,9 +263,6 @@ To facilitate incremental progress, initial intrinsic API for a given `static cl
263263

264264
As intrinsic support is added test coverage must be extended to provide basic testing.
265265

266-
Tests should be added as soon as practical. CoreCLR Implementation and CoreFX API will need to be merged before tests
267-
can be merged.
268-
269266
## LSRA changes to allocate contiguous register ranges
270267

271268
Some ARM64 instructions will require allocation of contiguous blocks of registers. These are likely limited to load and

docs/design/features/hw-intrinsics.md

Lines changed: 1 addition & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -10,11 +10,7 @@ There is a design document for the Arm64 intrinsics: https://github.com/dotnet/r
1010

1111
## Overview
1212

13-
The reference assemblies for the hardware intrinsics live in corefx, but all of the implementation is in the coreclr repo:
14-
15-
* 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.
16-
17-
* Note that they are mirrored to other repositories, including corefx, corert and mono.
13+
* 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.
1814

1915
## C# Implementation
2016

docs/project/glossary.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -14,13 +14,13 @@ terminology.
1414
| AOT | Ahead-of-time compiler. Converts the MSIL bytecode to native machine code for a specific target CPU architecture. |
1515
| BBT | Microsoft internal early version of C/C++ PGO. See https://www.microsoft.com/windows/cse/bit_projects.mspx. |
1616
| BOTR | Book Of The Runtime. |
17-
| 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. |
17+
| 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. |
1818
| CIL | Common Intermediate Language. Equivalent to IL, also equivalent to [MSIL](https://learn.microsoft.com/dotnet/standard/managed-execution-process#compiling-to-msil). |
1919
| CLI | Command Line Interface, or Common Language Infastructure. |
2020
| CLR | [Common Language Runtime](https://learn.microsoft.com/dotnet/standard/clr). |
2121
| 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). |
2222
| COR | [Common Object Runtime](http://www.danielmoth.com/Blog/mscorlibdll.aspx). The name of .NET before it was named .NET. |
23-
| 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) |
23+
| 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. |
2424
| DAC | Data Access Component. An abstraction layer over the internal structures in the runtime. |
2525
| EE | [Execution Engine](https://learn.microsoft.com/dotnet/standard/managed-execution-process#running_code). |
2626
| 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).
285285
## Engineering system
286286

287287
* **Helix**. It's a massively-parallel, general-purpose job processing and
288-
result aggregation system running in the cloud. The work items that corefx
289-
sends to Helix are [xunit][xunit] tests. Test results are shown through the
288+
result aggregation system running in the cloud. The work items that we
289+
send to Helix are [xunit][xunit] tests. Test results are shown through the
290290
[*Mission Control* reporting site][mc.dot.net]; to go to the test results in a
291291
PR from Azure DevOps, you can click on the *Send to Helix* step in the build,
292292
and the logs will have the URL.

docs/project/issue-guide.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,14 @@
11
Issue Guide
22
===========
33

4-
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.
4+
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.
55

66
### When we close issues
77
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:
88

9-
1. Issues unrelated to CoreFx. When possible, we'll try to find a better home for the issue and point you to it.
9+
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.
1010
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.
11-
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.
11+
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.
1212

1313
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.
1414

@@ -78,8 +78,8 @@ Feel free to use other labels if it helps your triage efforts (e.g. **needs more
7878

7979
1. Each PR has exactly one **area-\*** label
8080
* Movitation: Area owners will get email notification about new issue in their area.
81-
1. PR has **Assignee** set to author of the PR, if it is non-CoreFX engineer, then area owners are co-assignees
82-
* 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.
81+
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
82+
* Motivation #1: Area owners are responsible to do code reviews for PRs from external contributors. Committers know how to get code reviews from others.
8383
* Motivation #2: Assignees will get notifications for anything happening on the PR.
8484
1. [Optional] Set milestone according to the branch the PR is against (main = 6.0, release/5.0 = 5.0)
8585
* 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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -112,7 +112,7 @@ Not yet clear what porting this entails.
112112
### Leverage peer repo test suites.
113113

114114
We should be able to directly leverage tests provided in peer repo suites, once
115-
they can run on top of CoreCLR. In particular CoreFx and Roslyn test cases
115+
they can run on top of CoreCLR. In particular libraries and Roslyn test cases
116116
could be good initial targets.
117117

118118
Note LLILC is currently working through the remaining issues that prevent it

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

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
1-
Debugging CoreFX on Unix
2-
==========================
1+
Debugging core .NET libraries on Unix
2+
=====================================
33

4-
CoreFX can be debugged on unix using both lldb and visual studio code
4+
.NET can be debugged on unix using both lldb and Visual Studio Code.
55

66
## Using lldb and SOS
77

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

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
1-
Debugging CoreFX on Windows
2-
==========================
1+
Debugging core .NET libraries on Windows
2+
========================================
33

44
You can Debug .NET via Visual Studio or WinDBG.
55

@@ -37,11 +37,11 @@ For example: `src\System.Net.Sockets\tests\Functional\System.Net.Sockets.Tests.c
3737

3838
* Execute the test
3939

40-
Assuming that your repo is at `C:\corefx`:
40+
Assuming that your repo is at `C:\root`:
4141

4242
```
43-
cd C:\corefx\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0
44-
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
43+
cd C:\root\bin\tests\windows.AnyCPU.Debug\System.Net.Sockets.Tests\netcoreapp1.0
44+
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
4545
```
4646

4747
* 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
5252
.symfix
5353
.srcfix
5454
.reload
55-
!load C:\corefx\packages\runtime.win7-x64.Microsoft.NETCore.Runtime.CoreCLR\<version>\tools\sos
55+
!load C:\root\packages\runtime.win7-x64.Microsoft.NETCore.Runtime.CoreCLR\<version>\tools\sos
5656
```
5757

5858
_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.
137137
138138
### Built-in EventSource tracing
139139
140-
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.
140+
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.
141141
142142
#### Global
143143
* `*System.Diagnostics.Eventing.FrameworkEventSource {8E9F5090-2D75-4d03-8A81-E5AFBF85DAF1}`: Global EventSource used by multiple namespaces.

0 commit comments

Comments
 (0)