Sync with upstream main branch

.config/dotnet-tools.json

@@ -3,7 +3,7 @@
   "isRoot": true,
   "tools": {
     "coverlet.console": {
-      "version": "3.1.0",
+      "version": "3.1.2",
       "commands": [
         "coverlet"
       ]
@@ -15,13 +15,13 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "1.0.0-prerelease.22101.2",
+      "version": "1.0.0-prerelease.22114.1",
       "commands": [
         "xharness"
       ]
     },
     "microsoft.visualstudio.slngen.tool": {
-      "version": "6.3.0",
+      "version": "8.1.6",
       "commands": [
         "slngen"
       ]

.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md

@@ -21,3 +21,8 @@ main PR <!-- Link to PR if any that fixed this in the main branch. -->
 # Risk
 
 <!-- Please assess the risk of taking this fix. Provide details backing up your assessment. -->
+
+# Package authoring signed off?
+
+
+IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary [package authoring](https://github.com/dotnet/runtime/blob/main/docs/project/library-servicing.md) and gotten it explicitly reviewed.

.github/workflows/backport.yml

@@ -22,7 +22,7 @@ jobs:
           if (context.eventName !== "issue_comment") throw "Error: This action only works on issue_comment events.";
 
           // extract the target branch name from the trigger phrase containing these characters: a-z, A-Z, digits, forward slash, dot, hyphen, underscore
-          const regex = /\/backport to ([a-zA-Z\d\/\.\-\_]+)/;
+          const regex = /^\/backport to ([a-zA-Z\d\/\.\-\_]+)/;
           target_branch = regex.exec(context.payload.comment.body);
           if (target_branch == null) throw "Error: No backport branch found in the trigger phrase.";
 
@@ -57,3 +57,5 @@ jobs:
           ## Testing
 
           ## Risk
+
+          IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary [package authoring](https://github.com/dotnet/runtime/blob/main/docs/project/library-servicing.md) and gotten it explicitly reviewed.

Directory.Build.props

@@ -305,5 +305,6 @@
   <PropertyGroup>
     <CustomBeforeNoTargets>$(RepositoryEngineeringDir)NoTargetsSdk.BeforeTargets.targets</CustomBeforeNoTargets>
     <CustomAfterTraversalProps>$(RepositoryEngineeringDir)TraversalSdk.AfterProps.props</CustomAfterTraversalProps>
+    <CustomAfterTraversalTargets>$(RepositoryEngineeringDir)TraversalSdk.AfterTargets.targets</CustomAfterTraversalTargets>
   </PropertyGroup>
 </Project>

Directory.Build.targets

@@ -26,6 +26,10 @@
     <InformationalVersion Condition="'$(InformationalVersion)' == '' and '$(VersionSuffix)' != ''">$(ProductVersion)-$(VersionSuffix)</InformationalVersion>
   </PropertyGroup>
 
+  <ItemGroup>
+    <SupportedNETCoreAppTargetFramework Include=".NETCoreApp,Version=v$(NETCoreAppMaximumVersion)" DisplayName=".NET $(NETCoreAppMaximumVersion)" Alias="net$(NETCoreAppMaximumVersion)" />
+  </ItemGroup>
+
   <!-- The Default behavior in VS is to show files for the first target framework in TargetFrameworks property.
        This is required to show all the files corresponding to all target frameworks in VS. -->
   <ItemGroup Condition="'$(DefaultLanguageSourceExtension)' != '' and

THIRD-PARTY-NOTICES.TXT

@@ -1026,3 +1026,25 @@ a. No trademark or patent rights held by Affirmer are waived, abandoned, surrend
 b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law.
 c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work.
 d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work.
+
+
+License notice for FastFloat algorithm
+-------------------------------------
+MIT License
+Copyright (c) 2021 csFastFloat authors
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+

docs/area-owners.md

@@ -165,5 +165,6 @@ The repo has a number of community members carrying the triager role. While not
 
 * @huoyaoyuan
 * @SingleAccretion
+* @teo-tsirpanis
 * @tmds
 * @vcsjones

docs/coding-guidelines/project-guidelines.md

@@ -22,7 +22,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
 
-- `$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net5.0`
+- `$(BuildTargetFramework) -> Any .NETCoreApp or .NETFramework TFM, e.g. net7.0`
 - `$(TargetOS) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
 - `$(Configuration) -> Release | [defaults to Debug when empty]`
 - `$(TargetArchitecture) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]`
@@ -37,22 +37,18 @@ Each project will define a set of supported TargetFrameworks
 <PropertyGroup>
 ```
 
-- `$(BuildSettings) -> $(BuildTargetFramework)[-$(TargetOS)][-$(Configuration)][-$(TargetArchitecture)]`
- - Note this property should be file path safe and thus can be used in file names or directories that need to a unique path for a project configuration.
- - The only required Build Settings value is the `$(BuildTargetFramework)` the others are optional.
-
 Example:
-Pure netstandard configuration:
+Non cross-targeting project that targets .NETStandard:
 ```
 <PropertyGroup>
-  <TargetFrameworks>netstandard2.0</TargetFrameworks>
+  <TargetFramework>netstandard2.0</TargetFramework>
 <PropertyGroup>
 ```
 
-All supported targets with unique windows/unix build for netcoreapp:
+A cross-targeting project which targets specific platform with `$(NetCoreAppCurrent)` and one .NETFramework tfm:
 ```
 <PropertyGroup>
-  <TargetFrameworks>$(NetCoreAppCurrent)-windows;$(NetCoreAppCurrent)-Unix;$(NetFrameworkCurrent)</TargetFrameworks>
+  <TargetFrameworks>$(NetCoreAppCurrent)-windows;$(NetCoreAppCurrent)-Unix;$(NetFrameworkMinimum)</TargetFrameworks>
 <PropertyGroup>
 ```
 
@@ -61,15 +57,15 @@ All supported targets with unique windows/unix build for netcoreapp:
 A full or individual project build is centered around BuildTargetFramework, TargetOS, Configuration and TargetArchitecture.
 
 1. `$(BuildTargetFramework), $(TargetOS), $(Configuration), $(TargetArchitecture)` can individually be passed in to change the default values.
-2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `net5.0-[TargetOS Running On]-Debug-x64`.
-3. While Building an individual project from the VS, we build the project for all latest netcoreapp target frameworks.
+2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `net7.0-[TargetOS Running On]-Debug-x64`.
+3. When building an individual project (either from the CLI or an IDE), all target frameworks are built.
 
 We also have `RuntimeOS` which can be passed to customize the specific OS and version needed for native package builds as well as package restoration. If not passed it will default based on the OS you are running on.
 
-Any of the mentioned properties can be set via `/p:<Property>=<Value>` at the command line. When building using our run tool or any of the wrapper scripts around it (i.e. build.cmd) a number of these properties have aliases which make them easier to pass (run build.cmd/sh -? for the aliases).
+Any of the mentioned properties can be set via `/p:<Property>=<Value>` at the command line. When building using any of the wrapper scripts around it (i.e. build.cmd) a number of these properties have aliases which make them easier to pass (run build.cmd/sh -? for the aliases).
 
 ## Selecting the correct BuildSettings
-When building an individual project the `BuildTargetFramework` and `TargetOS` will be used to select the closest matching TargetFramework listed in the projects `TargetFrameworks` property. The rules used to select the targetFramework will consider compatible target frameworks and OS fallbacks.
+When building an individual project the `BuildTargetFramework` and `TargetOS` will be used to select the compatible dependencies which are expressed as ProjectReference items.
 
 ## Supported full build settings
 - .NET Core latest on current OS (default) -> `$(NetCoreAppCurrent)-[RunningOS]`
@@ -80,37 +76,64 @@ When building an individual project the `BuildTargetFramework` and `TargetOS` wi
 ## TargetFramework conditions
 `TargetFramework` conditions should be avoided in the first PropertyGroup as that causes DesignTimeBuild issues: https://github.com/dotnet/project-system/issues/6143
 
-1. Use an equality check if the TargetFramework isn't overloaded with the OS portion.
+1. Use TargetFrameworkIdentifier to condition on an entire framework to differentiate between .NETCoreApp, .NETStandard and .NETFramework.
+Example:
+```
+<PropertyGroup>
+  <TargetFrameworks>$(NetCoreAppCurrent);netstandard2.0;$(NetFrameworkMinimum)</TargetFrameworks>
+</PropertyGroup>
+<ItemGroup Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'">...</ItemGroup>
+<ItemGroup Condition="'$(TargetFrameworkIdentifier)' == '.NETStandard'">...</ItemGroup>
+<ItemGroup Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework'">...</ItemGroup>
+```
+2. Use equality checks if you want to condition on specific runtime agnostic target frameworks (i.e. without the `-windows` suffix).
 Example:
 ```
 <PropertyGroup>
-  <TargetFrameworks>netstandard2.0;netstandard2.1</TargetFrameworks>
+  <TargetFrameworks>$(NetCoreAppCurrent);netstandard2.0;$(NetFrameworkMinimum)</TargetFrameworks>
 </PropertyGroup>
+<ItemGroup Condition="'$(TargetFramework)' == '$(NetCoreAppCurrent)'">...</ItemGroup>
 <ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">...</ItemGroup>
+<ItemGroup Condition="'$(TargetFramework)' == '$(NetFrameworkMinimum)'">...</ItemGroup>
 ```
-2. Use a StartsWith when you want to test for multiple .NETStandard or .NETFramework versions.
+3. Use the `TargetPlatformIdentifier` property to condition on a .NETCoreApp platform specific target framework. Note that .NETStandard and .NETFramework target frameworks can't be platform specific.
 Example:
 ```
 <PropertyGroup>
-  <TargetFrameworks>netstandard2.0;netstandard2.1</TargetFrameworks>
+  <TargetFrameworks>$(NetCoreAppCurrent)-windows;$(NetCoreAppCurrent)-OSX;$(NetCoreAppCurrent)</TargetFrameworks>
+</PropertyGroup>
+<ItemGroup Condition="'$(TargetPlatformIdentifier)' == 'windows'">...</ItemGroup>
+<ItemGroup Condition="'$(TargetPlatformIdentifier)' == 'OSX'">...</ItemGroup>
+```
+Important: In contrast to the old `Targets*` checks, `TargetPlatformIdentifier` conditions apply to a single tfm only, inheritance between target frameworks can't be expressed. See the example below for Unix:
+```
+<PropertyGroup>
+  <TargetFrameworks>$(NetCoreAppCurrent)-Unix;$(NetCoreAppCurrent)-Linux;$(NetCoreAppCurrent)-android;$(NetCoreAppCurrent)-windows</TargetFrameworks>
 </PropertyGroup>
-<ItemGroup Condition="$(TargetFramework.StartsWith('netstandard'))>...</ItemGroup>
+<ItemGroup Condition="'$(TargetPlatformIdentifier)' == 'Unix' or '$(TargetPlatformIdentifier)' == 'Linux' or '$(TargetPlatformIdentifier)' == 'android'">...</ItemGroup>
+<!-- Negations make such conditions easier to write and read. -->
+<ItemGroup Condition="'$(TargetPlatformIdentifier)' != 'windows'">...</ItemGroup>
 ```
-3. Use a StartsWith if the TargetFramework is overloaded with the OS portion.
+4. Set the `TargetPlatformIdentifier` property in the project to be able to condition on it in properties in the project file.
+That is necessary as the SDK sets the `TargetPlatformIdentifier` in a .targets file after the project is evaluated. Because of that, the property isn't available during the project's evaluation and must be set manually.
 Example:
 ```
 <PropertyGroup>
-  <TargetFrameworks>netstandard2.0-windows;netstandard2.0-Unix</TargetFrameworks>
+  <TargetFrameworks>$(NetCoreAppCurrent)-windows;$(NetCoreAppCurrent)-android</TargetFrameworks>
+</PropertyGroup>
+<!-- DesignTimeBuild requires all the TargetFramework Derived Properties to not be present in the first property group. -->
+<PropertyGroup>
+  <TargetPlatformIdentifier>$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)'))</TargetPlatformIdentifier>
+  <DefineConstants Condition="'$(TargetPlatformIdentifier)' == 'android'">$(DefineConstants);ANDROID_USE_BUFFER</DefineConstants>
 </PropertyGroup>
-<ItemGroup Condition="$(TargetFramework.StartsWith('netstandard2.0'))>...</ItemGroup>
 ```
-4. Use negations if that makes the conditions easier.
+5. Use negations if that makes the conditions easier.
 Example:
 ```
 <PropertyGroup>
-  <TargetFrameworks>netstandard2.0;net462;net472;net5.0</TargetFrameworks>
+  <TargetFrameworks>$(NetCoreAppCurrent);netstandard2.0;net462</TargetFrameworks>
 </PropertyGroup>
-<ItemGroup Condition="!$(TargetFramework.StartsWith('net4'))>...</ItemGroup>
+<ItemGroup Condition="'$(TargetFrameworkIdentifier)' != '.NETFramework'">...</ItemGroup>
 <ItemGroup Condition="'$(TargetFramework)' != 'netstandard2.0'">...</ItemGroup>
 ```
 
@@ -119,11 +142,10 @@ Example:
 Library projects should use the following directory layout.
 
 ```
-src\<Library Name>\src - Contains the source code for the library.
+src\<Library Name>\gen - Contains source code for the assembly's source generator.
 src\<Library Name>\ref - Contains any reference assembly projects for the library.
-src\<Library Name>\pkg - Contains package projects for the library.
+src\<Library Name>\src - Contains the source code for the library.
 src\<Library Name>\tests - Contains the test code for a library.
-src\<Library Name>\gen - Contains source code for the assembly's source generator.
 ```
 
 ## ref

docs/design/coreclr/botr/clr-abi.md

@@ -26,6 +26,8 @@ Arm corporation ABI documentation (for ARM32 and ARM64) is [here](https://develo
 
 The Linux System V x86_64 ABI is documented in [System V Application Binary Interface / AMD64 Architecture Processor Supplement](https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0.pdf), with document source material [here](https://gitlab.com/x86-psABIs/x86-64-ABI).
 
+The LoongArch64 ABI documentation is [here](https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc)
+
 # General Unwind/Frame Layout
 
 For all non-x86 platforms, all methods must have unwind information so the garbage collector (GC) can unwind them (unlike native code in which a leaf method may be omitted).
@@ -752,3 +754,43 @@ The return value is handled as follows:
 4. All other cases require the use of a return buffer, through which the value is returned.
 
 In addition, there is a guarantee that if a return buffer is used a value is stored there only upon ordinary exit from the method. The buffer is not allowed to be used for temporary storage within the method and its contents will be unaltered if an exception occurs while executing the method.
+
+# Control Flow Guard (CFG) support on Windows
+
+Control Flow Guard (CFG) is a security mitigation available in Windows.
+When CFG is enabled, the operating system maintains data structures that can be used to verify whether an address is to be considered a valid indirect call target.
+This mechanism is exposed through two different helper functions, each with different characteristics.
+
+The first mechanism is a validator that takes the target address as an argument and fails fast if the address is not an expected indirect call target; otherwise, it does nothing and returns.
+The second mechanism is a dispatcher that takes the target address in a non-standard register; on successful validation of the address, it jumps directly to the target function.
+Windows makes the dispatcher available only on ARM64 and x64, while the validator is available on all platforms.
+However, the JIT supports CFG only on ARM64 and x64, with CFG by default being disabled for these platforms.
+The expected use of the CFG feature is for NativeAOT scenarios that are running in constrained environments where CFG is required.
+
+The helpers are exposed to the JIT as standard JIT helpers `CORINFO_HELP_VALIDATE_INDIRECT_CALL` and `CORINFO_HELP_DISPATCH_INDIRECT_CALL`.
+
+To use the validator the JIT expands indirect calls into a call to the validator followed by a call to the validated address.
+For the dispatcher the JIT will transform calls to pass the target along but otherwise set up the call as normal.
+
+Note that "indirect call" here refers to any call that is not to an immediate (in the instruction stream) address.
+For example, even direct calls may emit indirect call instructions in JIT codegen due to e.g. tiering or if they have not been compiled yet; these are expanded with the CFG mechanism as well.
+
+The next sections describe the calling convention that the JIT expects from these helpers.
+
+## CFG details for ARM64
+
+On ARM64, `CORINFO_HELP_VALIDATE_INDIRECT_CALL` takes the call address in `x15`.
+In addition to the usual registers it preserves all float registers, `x0`-`x8` and `x15`.
+
+`CORINFO_HELP_DISPATCH_INDIRECT_CALL` takes the call address in `x9`.
+The JIT does not use the dispatch helper by default due to worse branch predictor performance.
+Therefore it will expand all indirect calls via the validation helper and a manual call.
+
+## CFG details for x64
+
+On x64, `CORINFO_HELP_VALIDATE_INDIRECT_CALL` takes the call address in `rcx`.
+In addition to the usual registers it also preserves all float registers and `rcx` and `r10`; furthermore, shadow stack space is not required to be allocated.
+
+`CORINFO_HELP_DISPATCH_INDIRECT_CALL` takes the call address in `rax` and it reserves the right to use and trash `r10` and `r11`.
+The JIT uses the dispatch helper on x64 whenever possible as it is expected that the code size benefits outweighs the less accurate branch prediction.
+However, note that the use of `r11` in the dispatcher makes it incompatible with VSD calls where the JIT must fall back to the validator and a manual call.

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

@@ -66,8 +66,9 @@ The limitations of the current format are:
 
 # Structures
 
-The structures and accompanying constants are defined in the [readytorun.h]
-(https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/readytorun.h) header file.
+The structures and accompanying constants are defined in the
+[readytorun.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/readytorun.h)
+header file.
 Basically the entire R2R executable image is addressed through the READYTORUN_HEADER singleton
 pointed to by the well-known export RTR_HEADER in the export section of the native executable
 envelope.