Merge remote-tracking branch 'upstream/master' into fewerEpolls

Directory.Build.props

@@ -24,6 +24,7 @@
     <RepositoryEngineeringDir>$([MSBuild]::NormalizeDirectory('$(RepoRoot)', 'eng'))</RepositoryEngineeringDir>
     <ArtifactsDir>$([MSBuild]::NormalizeDirectory('$(RepoRoot)', 'artifacts'))</ArtifactsDir>
     <ArtifactsBinDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsDir)', 'bin'))</ArtifactsBinDir>
+    <ArtifactsObjDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsDir)', 'obj'))</ArtifactsObjDir>
   </PropertyGroup>
 
   <!-- The TFMs to build and test against. -->
@@ -34,6 +35,8 @@
     <NetFrameworkCurrent>net472</NetFrameworkCurrent>
   </PropertyGroup>
 
+  <Import Project="$(RepositoryEngineeringDir)Configurations.props" />
+
   <!--
     Get ProjectToBuild and '<subset>ProjectToBuild' items. Using the items lets projects handle
     $(Subset) automatically when creating project-to-project dependencies.
@@ -52,14 +55,6 @@
     <CoreLibSharedDir>$([MSBuild]::NormalizeDirectory('$(LibrariesProjectRoot)', 'System.Private.CoreLib', 'src'))</CoreLibSharedDir>
   </PropertyGroup>
 
-  <!-- Honor the generic RuntimeConfiguration property. -->
-  <PropertyGroup>
-    <CoreCLRConfiguration Condition="'$(CoreCLRConfiguration)' == ''">$(RuntimeConfiguration)</CoreCLRConfiguration>
-    <MonoConfiguration Condition="'$(MonoConfiguration)' == '' and '$(RuntimeConfiguration.ToLower())' != 'checked'">$(RuntimeConfiguration)</MonoConfiguration>
-    <!-- There's no checked configuration on Mono. -->
-    <MonoConfiguration Condition="'$(MonoConfiguration)' == '' and '$(RuntimeConfiguration.ToLower())' == 'checked'">Debug</MonoConfiguration>
-  </PropertyGroup>
-
   <!-- Packaging properties -->
   <PropertyGroup>
     <!--

docs/README.md

@@ -70,7 +70,7 @@ Other Information
 
 - [.NET Glossary](project/glossary.md)
 - [.NET Filename Encyclopedia](project/dotnet-filenames.md)
-- [Porting to .NET Core](project/support-dotnet-core-instructions.md)
+- [Porting to .NET Core](https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer)
 - [.NET Standards (Ecma)](project/dotnet-standards.md)
 - [CLR Configuration Knobs](../src/coreclr/src/inc/clrconfigvalues.h)
 - [CLR overview](https://docs.microsoft.com/dotnet/standard/clr)

docs/coding-guidelines/project-guidelines.md

@@ -8,7 +8,7 @@ once before you can iterate and work on a given library project.
 - Restore external dependencies
  - CoreCLR - Copy to `bin\runtime\$(BuildConfiguration)`
  - Netstandard Library - Copy to `bin\ref\netstandard`
- - NetFx targeting pack - Copy to `bin\ref\netfx`
+ - NetFx targeting pack - Copy to `bin\ref\net472`
 - Build targeting pack
  - Build src\ref.builds which builds all references assembly projects. For reference assembly project information see [ref](#ref)
 - Build product
@@ -37,7 +37,7 @@ Below is a list of all the various options we pivot the project builds on:
 ## Individual build properties
 The following are the properties associated with each build pivot
 
-- `$(TargetGroup) -> netstandard | netcoreapp | netfx`
+- `$(TargetGroup) -> netstandard2.1 | netcoreapp5.0 | net472`
 //**CONSIDER**: naming netcoreappcorert something shorter maybe just corert.
 - `$(OSGroup) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
 - `$(ConfigurationGroup) -> Release | [defaults to Debug when empty]`
@@ -77,9 +77,9 @@ All supported targets with unique windows/unix build for netcoreapp:
 ```
 <PropertyGroup>
   <BuildConfigurations>
-    netcoreapp-Windows_NT;
-    netcoreapp-Unix;
-    netfx-Windows_NT;
+    $(NetCoreAppCurrent)-Windows_NT;
+    $(NetCoreAppCurrent)-Unix;
+    $(NetFrameworkCurrent)-Windows_NT;
   </BuildConfigurations>
 <PropertyGroup>
 ```
@@ -90,12 +90,12 @@ Placeholder build configurations can be added to the `<BuildConfigurations>` pro
 Placeholder build configurations start with _ prefix.
 
 Example:
-When we have a project that has a `netstandard` build configuration that means that this project is compatible with any build configuration. So if we do a vertical build for `netfx` this project will be built as part of the vertical because `netfx` is compatible with `netstandard`. This means that in the runtime and testhost binaries the netstandard implementation will be included, and we will test against those assets instead of testing against the framework inbox asset. In order to tell the build system to not include this project as part of the `netfx` vertical we need to add a placeholder configuration:
+When we have a project that has a `netstandard` build configuration that means that this project is compatible with any build configuration. So if we do a vertical build for `net472` this project will be built as part of the vertical because `net472` is compatible with `netstandard2.0`. This means that in the runtime and testhost binaries the netstandard implementation will be included, and we will test against those assets instead of testing against the framework inbox asset. In order to tell the build system to not include this project as part of the `net472` vertical we need to add a placeholder configuration:
 ```
 <PropertyGroup>
   <BuildConfigurations>
-    netstandard;
-    _netfx;
+    netstandard2.0;
+    _net472;
   </BuildConfigurations>
 </PropertyGroup>
 ```
@@ -120,8 +120,8 @@ TODO: Link to the target framework and OS fallbacks when they are available.
 Temporary versions are at https://github.com/dotnet/corefx/blob/dev/eng/src/Tools/GenerateProps/osgroups.props and https://github.com/dotnet/corefx/blob/dev/eng/src/Tools/GenerateProps/targetgroups.props
 
 ## Supported full build configurations
-- .NET Core latest on current OS (default) -> `netcoreapp-[RunningOS]`
-- .NET Framework latest -> `netfx-Windows_NT`
+- .NET Core latest on current OS (default) -> `$(NetCoreAppCurrent)-[RunningOS]`
+- .NET Framework latest -> `$(NetFrameworkCurrent)-Windows_NT`
 
 ## Project configurations for VS
 For each unique configuration needed for a given library project a configuration entry separated by a ';' should be added to the project so it can be selected and built in VS and also clearly identify the various configurations.<BR/>

docs/design/coreclr/botr/readytorun-format.md

@@ -119,6 +119,7 @@ enum ReadyToRunSectionType
     READYTORUN_SECTION_PROFILEDATA_INFO             = 111, // Added in V2.2
     READYTORUN_SECTION_MANIFEST_METADATA            = 112, // Added in V2.3
     READYTORUN_SECTION_ATTRIBUTEPRESENCE            = 113, // Added in V3.1
+    READYTORUN_SECTION_INLINING_INFO2               = 114, // Added in V4.1
 };
 ```
 
@@ -428,6 +429,19 @@ The module override index translation algorithm is as follows (**ILAR** = *the n
 
 **TODO**: document attribute presence encoding
 
+## READYTORUN_SECTION_INLINING_INFO2
+
+The inlining information section captures what methods got inlined into other methods. It consists of a single _Native Format Hashtable_ (described below).
+
+The entries in the hashtable are lists of inliners for each inlinee. One entry in the hashtable corresponds to one inlinee. The hashtable is hashed by hashcode of the module name XORed with inlinee RID.
+
+The entry of the hashtable is a counted sequence of compressed unsigned integers:
+
+* RID of the inlinee shifted left by one bit. If the lowest bit is set, this is an inlinee from a foreign module. The _module override index_ (as defined above) follows as another compressed unsigned integer in that case.
+* RIDs of the inliners follow. They are encoded similarly to the way the inlinee is encoded (shifted left with the lowest bit indicating foreign RID). Instead of encoding the RID directly, RID delta (the difference between the previous RID and the current RID) is encoded. This allows better integer compression.
+
+Foreign RIDs are only present if a fragile inlining was allowed at compile time.
+
 # Native Format
 
 Native format is set of encoding patterns that allow persisting type system data in a binary format that is

docs/pr-guide.md

@@ -19,20 +19,33 @@ Every pull request will have automatically a single `area-*` label assigned. The
 If during the code review process a merge conflict occurs the area owner is responsible for its resolution. Pull requests should not be on hold due to the author's unwillingness to resolve code conflicts. GitHub makes this easier by allowing simple conflict resolution using the [conflict-editor](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github).
 
 ## Merging Pull Requests
+
 Anyone with write access can merge a pull request manually or by setting the [auto-merge](/labels/auto-merge) label when it satisfies all of the following conditions:
 
 * The PR has been approved by at least one reviewer and any other objections are addressed.
     * You can request another review from the original reviewer.
 * The PR successfully builds and passes all tests in the Continuous Integration (CI) system.
     * You can trigger a rebuild by adding a comment like `/azp run <pipeline name>` or manually re-run only the failing lanes in Azure DevOps tab.
     * Reach out to the infrastructure team for assistance on [Teams channel](https://teams.microsoft.com/l/channel/19%3ab27b36ecd10a46398da76b02f0411de7%40thread.skype/Infrastructure?groupId=014ca51d-be57-47fa-9628-a15efcc3c376&tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47) (for corpnet users) or on [Gitter](https://gitter.im/dotnet/community) in other cases.
- * In rare cases the pull request can be merged with failing tests if the person merging it also creates tracking issue for flaky tests.
 
 Please always **squash** the pull request unless there are special circumstances. Do so, even if the PR contains only one commit. It creates a simpler history than a Merge Commit. "Special circumstances" are rare, and typically mean that there are a series of cleanly separated changes that will be too hard to understand if squashed together, or for some reason we want to preserve the ability to bisect them.
 
+## Unrelated failure
+
+In case CI indicates failures which are **highly unlikely** to be caused by changes in the PR, the following actions should be taken:
+
+* An existing issue in the repository should be searched for. Usually the test method's or the test assembly's name (in case of a crash) are good parameters.
+* If there's an existing issue, a comment should be placed that includes a) the link to the build, b) the affected configuration (ie `netcoreapp-Windows_NT-Release-x64-Windows.81.Amd64.Open`) and c) the Error message and Stack trace. This is necessary as retention policies are in place that recycle _old_ builds. In case the issue is already closed, it should be reopened and labels should be updated to reflect the current failure state. 
+* If there's no existing issue, an issue should be created with the same information outlined above.
+* In a follow-up Pull Request, the failing test(s) should be disabled with the corresponding issue number, e.g. `[ActiveIssue(x)]`, and the tracking issue should be labeled as `disabled-test`.
+* A comment should be placed in the original Pull Request that links to the created or updated issues.
+
+There are plenty of possible bugs, e.g. race conditions, where a failure might highlight a real problem and it won't manifest again on a retry. Therefore these steps should be followed for every iteration of the PR build, e.g. before retrying/rebuilding.
+
 ## Blocking Pull Request Merging
 
 If for whatever reason you would like to move your pull request back to an in-progress status to avoid merging it in the current form, you can do that by adding [WIP] prefix to the pull request title.
 
 ## Old Pull Request Policy
+
 From time to time we will review older PR's (> 1 month) and check them for relevance. If we find the PR is inactive or no longer applies, we will close it. As the PR owner, you can simply reopen it if you feel your closed PR needs our attention.

docs/project/garbage-collector-guidelines.md

@@ -26,7 +26,7 @@ Required Testing: Validation of the behavior of the affected APIs.
 ## Stress Testing ##
 Stress testing must run for at least **48 hours** against a debug build.
 
-Stress testing for checked and release builds can be run locally. Please following the instructions described in tests\src\GC\Stress\stress_run_readme.txt. You can also request it on pull requests with The .NET CI infrastructure with the trigger phrase:
+Stress testing for checked and release builds can be run locally. Please following the instructions described in [gc-stress-run-readme.md](https://github.com/dotnet/runtime/blob/master/docs/workflow/testing/coreclr/gc-stress-run-readme.md). You can also request it on pull requests with The .NET CI infrastructure with the trigger phrase:
 
 ```
 @dotnet_bot test <platform> <flavor> gc_reliability_framework
@@ -62,4 +62,6 @@ due to poor interactions with the Linux OOM killer. However, they have proven to
 ```
 
 ## Performance Testing ##
-Coming soon.
+Performance tests can be run using the GC Benchmarking Infrastructure hosted within the [benchmarks section](https://github.com/dotnet/performance/tree/master/src/benchmarks/gc) of the _performance_ repo. This tool allows you to run the tests capturing traces through PerfView, and later analyze such traces for detailed results on GC's, heaps, and related behaviors. These tests also allow you to directly compare behaviors and metrics between different .NET builds and machines.
+
+The _README.md_ located at the link mentioned above contains detailed instructions on how to setup and use the tool. Additionally, there is a _docs_ section with all the information to perform further analysis on the traces.