Backport pr 111723 to 8.0 staging

.config/dotnet-tools.json

@@ -15,7 +15,7 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "8.0.0-prerelease.23407.2",
+      "version": "8.0.0-prerelease.25064.4",
       "commands": [
         "xharness"
       ]

.config/tsaoptions.json

@@ -2,9 +2,10 @@
     "instanceUrl": "https://devdiv.visualstudio.com/",
     "template": "TFSDEVDIV",
     "projectName": "DEVDIV",
-    "areaPath": "DevDiv\\NET Libraries",
+    "areaPath": "DevDiv\\NET Runtime",
     "iterationPath": "DevDiv",
     "notificationAliases": [ "runtimerepo-infra@microsoft.com" ],
     "repositoryName": "Runtime",
-    "codebaseName": "Runtime"
-}
+    "codebaseName": "Runtime",
+    "serviceTreeId": "1dc8dedc-8f5f-4b94-b182-ec3bdfb207b0"
+}

.github/workflows/check-no-merge-label.yml

@@ -0,0 +1,25 @@
+name: check-no-merge-label
+
+permissions:
+  pull-requests: read
+
+on:
+  pull_request:
+    types: [opened, edited, reopened, labeled, unlabeled, synchronize]
+    branches:
+      - 'main'
+      - 'release/**'
+
+jobs:
+  check-labels:
+    runs-on: ubuntu-latest
+    steps:
+    - name: Check 'NO-MERGE' label
+      run: |
+        echo "Merging permission is disabled when the 'NO-MERGE' label is applied."
+        if [ "${{ contains(github.event.pull_request.labels.*.name, 'NO-MERGE') }}" = "false" ]; then
+          exit 0
+        else
+          echo "::error:: The 'NO-MERGE' label was applied to the PR. Merging is disabled."
+          exit 1
+        fi

.github/workflows/check-service-labels.yml

@@ -15,7 +15,7 @@ jobs:
     steps:
     - name: Check 'Servicing-approved' label
       run: |
-        echo "Merging permission is enabled for servicing PRs when the `Servicing-approved` label is applied."
+        echo "Merging permission is enabled for servicing PRs when the 'Servicing-approved' label is applied."
         if [ "${{ contains(github.event.pull_request.labels.*.name, 'Servicing-approved') }}" = "true" ]; then
           exit 0
         else

.github/workflows/inter-branch-merge-flow.yml

@@ -0,0 +1,13 @@
+name: Inter-branch merge workflow
+on:
+  push:
+    branches:
+      - release/**
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  Merge:
+    uses: dotnet/arcade/.github/workflows/inter-branch-merge-base.yml@main

Directory.Build.props

@@ -114,8 +114,8 @@
     <NetFrameworkCurrent Condition="'$(DotNetBuildFromSource)' == 'true'" />
 
     <!-- Important: Set this to the GA version (or a close approximation) during servicing and adjust the TFM property below. -->
-    <ApiCompatNetCoreAppBaselineVersion>7.0.0</ApiCompatNetCoreAppBaselineVersion>
-    <ApiCompatNetCoreAppBaselineTFM>net7.0</ApiCompatNetCoreAppBaselineTFM>
+    <ApiCompatNetCoreAppBaselineVersion>8.0.0</ApiCompatNetCoreAppBaselineVersion>
+    <ApiCompatNetCoreAppBaselineTFM>net8.0</ApiCompatNetCoreAppBaselineTFM>
 
     <TargetFrameworkForNETFrameworkTasks>$(NetFrameworkToolCurrent)</TargetFrameworkForNETFrameworkTasks>
     <!-- Don't build for NETFramework during source-build. -->

NuGet.config

@@ -7,6 +7,13 @@
   </fallbackPackageFolders>
   <packageSources>
     <clear />
+    <!--Begin: Package sources managed by Dependency Flow automation. Do not edit the sources below.-->
+    <!--  Begin: Package sources from dotnet-emsdk -->
+    <add key="darc-pub-dotnet-emsdk-b767aab" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/darc-pub-dotnet-emsdk-b767aaba/nuget/v3/index.json" />
+    <!--  End: Package sources from dotnet-emsdk -->
+    <!--  Begin: Package sources from dotnet-sdk -->
+    <!--  End: Package sources from dotnet-sdk -->
+    <!--End: Package sources managed by Dependency Flow automation. Do not edit the sources above.-->
     <!--
       'src/test/PrepareTestAssets/PrepareTestAssets.proj' generates a NuGet.config file using this
       one as a template. The following line is a marker to insert the test restore sources.
@@ -23,5 +30,9 @@
   </packageSources>
   <disabledPackageSources>
     <clear />
+    <!--Begin: Package sources managed by Dependency Flow automation. Do not edit the sources below.-->
+    <!--  Begin: Package sources from dotnet-sdk -->
+    <!--  End: Package sources from dotnet-sdk -->
+    <!--End: Package sources managed by Dependency Flow automation. Do not edit the sources above.-->
   </disabledPackageSources>
 </configuration>

THIRD-PARTY-NOTICES.TXT

@@ -73,7 +73,7 @@ https://github.com/madler/zlib
 https://zlib.net/zlib_license.html
 
 /* zlib.h -- interface of the 'zlib' general purpose compression library
-  version 1.2.13, October 13th, 2022
+  version 1.3.1, January 22nd, 2024
 
   Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler
 
@@ -480,8 +480,8 @@ Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital
 Equipment Corporation makes any representations about the
 suitability of this software for any purpose."
 
-License notice for The LLVM Compiler Infrastructure
----------------------------------------------------
+License notice for The LLVM Compiler Infrastructure (Legacy License)
+--------------------------------------------------------------------
 
 Developed by:
 
@@ -986,8 +986,8 @@ 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.
 
-License for remote stack unwind (https://github.com/llvm/llvm-project/blob/main/lldb/source/Symbol/CompactUnwindInfo.cpp)
---------------------------------------
+License notice for The LLVM Project
+-----------------------------------
 
 Copyright 2019 LLVM Project
 

docs/coding-guidelines/libraries-packaging.md

@@ -18,6 +18,14 @@ Source generators and analyzers can be included in the shared framework by addin
 
 Removing a library from the shared framework is a breaking change and should be avoided.
 
+### References to libraries in the shared framework that produce packages
+
+It's beneficial to avoid project references to libraries that are in the shared framework because it makes the package graph smaller which reduces the number of packages that require servicing and the number of libraries that end up being copied into the application directory.
+
+If a dependency is part of the shared framework a project/package reference is never required on the latest version (`NetCoreAppCurrent`).  A reference is required for previous .NET versions even if the dependency is part of the shared framework if the project you are building targets .NETStandard and references the project there.  You may completely avoid a package dependency on .NETStandard and .NET if it's not needed for .NETStandard (for example - if it is an implementation only dependency and you're building a PNSE assembly for .NETStandard).
+
+Warning NETPKG0001 is emitted when you have an unnecessary reference to a library that is part of the shared framework.  To avoid this warning, make sure your ProjectReference is conditioned so that it doesn't apply on `NetCoreAppCurrent`.
+
 ## Transport package
 
 Transport packages are non-shipping packages that dotnet/runtime produces in order to share binaries with other repositories.
@@ -55,11 +63,47 @@ Packages can include a Markdown Readme file with a short usage documentation. To
 The package Readme is displayed on the package details page on [NuGet gallery](https://nuget.org/). You can include the following content in it:
 
 - A description of the package purpose.
+- A list of package key features
+- A code example that demostrates how to use the package.
 - Information when package should be used. For example, if the library is included in the shared framework in .NET, but needs to be installed via NuGet on .NET Framework, it should be mentioned.
-- Information on how to get started with the package.
-- Links to related documentation.
 - A list of common entry-point types for the package, with links to their API docs under [.NET API Browser](https://learn.microsoft.com/dotnet/api/).
-- A short code example that demostrates the package usage.
+- Links to related documentation.
+- Information about how to provide feedback on the package and contribute to it.
+
+Use the following Markdown template for a package Readme:
+
+```
+## About
+
+<!-- A description of the package and where one can find more documentation -->
+
+## Key Features
+
+<!-- The key features of this package -->
+
+## How to Use
+
+<!-- A compelling example on how to use this package with code, as well as any specific guidelines for when to use the package -->
+
+## Main Types
+
+<!-- The main types provided in this library -->
+
+## Additional Documentation
+
+* [Conceptual documentation](...)
+* [API documentation](...)
+
+## Related Packages
+
+<!-- The related packages associated with this package -->
+
+## Feedback & Contributing
+
+<!-- How to provide feedback on this package and contribute to it -->
+
+ExamplePackage is released as open source under the [MIT license](https://licenses.nuget.org/MIT). Bug reports and contributions are welcome at [the GitHub repository](https://github.com/dotnet/runtime).
+```
 
 For a list of supported Markdown features, see [NuGet documentation](https://learn.microsoft.com/nuget/nuget-org/package-readme-on-nuget-org#supported-markdown-features).
 

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

@@ -205,7 +205,7 @@ For non-rude thread abort, the VM walks the stack, running any catch handler tha
 
 For example:
 
-```
+```cs
 try { // try 1
     try { // try 2
         System.Threading.Thread.CurrentThread.Abort();
@@ -221,7 +221,7 @@ L:
 
 In this case, if the address returned in catch 2 corresponding to label L is outside try 1, then the ThreadAbortException re-raised by the VM will not be caught by catch 1, as is expected. The JIT needs to insert a block such that this is the effective code generation:
 
-```
+```cs
 try { // try 1
     try { // try 2
         System.Threading.Thread.CurrentThread.Abort();
@@ -238,7 +238,7 @@ L:
 
 Similarly, the automatic re-raise address for a ThreadAbortException can't be within a finally handler, or the VM will abort the re-raise and swallow the exception. This can happen due to call-to-finally thunks marked as "cloned finally", as described above. For example (this is pseudo-assembly-code, not C#):
 
-```
+```cs
 try { // try 1
     try { // try 2
         System.Threading.Thread.CurrentThread.Abort();
@@ -254,7 +254,7 @@ L:
 
 This would generate something like:
 
-```
+```asm
 	// beginning of 'try 1'
 	// beginning of 'try 2'
 	System.Threading.Thread.CurrentThread.Abort();
@@ -279,7 +279,7 @@ Finally1:
 
 Note that the JIT must already insert a "step" block so the finally will be called. However, this isn't sufficient to support ThreadAbortException processing, because "L1" is marked as "cloned finally". In this case, the JIT must insert another step block that is within "try 1" but outside the cloned finally block, that will allow for correct re-raise semantics. For example:
 
-```
+```asm
 	// beginning of 'try 1'
 	// beginning of 'try 2'
 	System.Threading.Thread.CurrentThread.Abort();
@@ -397,7 +397,7 @@ To implement this requirement, for any function with EH, we create a frame-local
 
 Note that the since a slot on x86 is 4 bytes, the minimum size is 16 bytes. The idea is to have 1 slot for each handler that could be possibly be invoked at the same time. For example, for:
 
-```
+```cs
 	try {
 		...
 	} catch {
@@ -417,7 +417,7 @@ When calling a finally, we set the appropriate level to 0xFC (aka "finally call"
 
 Thus, calling a finally from JIT generated code looks like:
 
-```
+```asm
 	mov      dword ptr [L_02+0x4 ebp-10H], 0 // This must happen before the 0xFC is written
 	mov      dword ptr [L_02+0x8 ebp-0CH], 252 // 0xFC
 	push     G_M52300_IG07
@@ -428,7 +428,7 @@ In this case, `G_M52300_IG07` is not the address after the 'jmp', so a simple 'c
 
 The code this finally returns to looks like this:
 
-```
+```asm
 	mov      dword ptr [L_02+0x8 ebp-0CH], 0
 	jmp      SHORT G_M52300_IG05
 ```
@@ -477,7 +477,7 @@ Because a main function body will **always** be on the stack when one of its fun
 
 There is one "corner case" in the VM implementation of WantsReportOnlyLeaf model that has implications for the code the JIT is allowed to generate. Consider this function with nested exception handling:
 
-```
+```cs
 public void runtest() {
     try {
         try {
@@ -804,3 +804,29 @@ In addition to the usual registers it also preserves all float registers and `rc
 `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.
+
+# Notes on Memset/Memcpy
+
+Generally, `memset` and `memcpy` do not provide any guarantees of atomicity. This implies that they should only be used when the memory being modified by `memset`/`memcpy` is not observable by any other thread (including GC), or when there are no atomicity requirements according to our [Memory Model](../../specs/Memory-model.md). It's especially important when we modify heap containing managed pointers - those must be updated atomically, e.g. using pointer-sized `mov` instruction (managed pointers are always aligned) - see [Atomic Memory Access](../../specs/Memory-model.md#Atomic-memory-accesses). It's worth noting that by "update" it's implied "set to zero", otherwise, we need a write barrier.
+
+Examples:
+
+```cs
+struct MyStruct
+{
+	long a;
+	string b;
+}
+
+void Test1(ref MyStruct m)
+{
+	// We're not allowed to use memset here
+	m = default;
+}
+
+MyStruct Test2()
+{
+	// We can use memset here
+	return default;
+}
+```

docs/design/features/dotnet-pgo.md

@@ -1,21 +1,13 @@
 # dotnet-pgo Spec
 Utilize trace data for improving application performance
 
-NOTE: This documentation page contains information on some features that are still work-in-progress.
-
 ## Intro
 
 The dotnet-pgo tool is a cross-platform CLI global tool that enables conversion of traces of .NET Core applications collected via dotnet-trace, ETW, perfview, perfcollect, LTTNG to be used to improve the performance of an application or library.
 
 ## Installing dotnet-pgo
 
-The first step is to install the dotnet-pgo CLI global tool.
-
-```cmd
-$ dotnet tool install --global dotnet-pgo
-You can invoke the tool using the following command: dotnet-pgo
-Tool 'dotnet-pgo' (version '6.0.47001') was successfully installed.
-```
+The only way to use dotnet-pgo is to build it in the runtime repo. To learn how to build the runtime, consult the [how to build](https://github.com/dotnet/runtime/tree/main/docs/workflow/building/coreclr) docs for Windows, macOS, or Linux.
 
 ## Using dotnet-pgo to optimize an application
 
@@ -37,14 +29,14 @@ set DOTNET_TC_QuickJitForLoops=1
 set DOTNET_TC_CallCountThreshold=10000
 set DOTNET_ReadyToRun=0
 
-dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:0x1E000080018:4 -- bin\Release\net6.0\pgotest.exe
+dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:0x1E000080018:4 -- bin\Release\net{version-number-goes-here}.0\pgotest.exe
 
 set DOTNET_TieredPGO=
 set DOTNET_TC_QuickJitForLoops=
 set DOTNET_TC_CallCountThreshold=
 set DOTNET_ReadyToRun=
 
-dotnet-pgo create-mibc --trace trace.nettrace --output trace.mibc
+${YOUR-REPO-ROOT}\artifacts\bin\coreclr\{OS}.{ARCHITECTURE}.{CONFIGURATION}\dotnet-pgo create-mibc --trace trace.nettrace --output trace.mibc
 
 dotnet publish --runtime win-x64 -p:PublishReadyToRun=true -p:ReadyToRunOptimizationData=trace.mibc
 ```

docs/project/library-servicing.md

@@ -4,6 +4,7 @@ This document provides the steps that need to be followed after modifying a libr
 
 Servicing branches represent shipped versions of .NET, and their name is in the format `release/X.0-staging`. Examples:
 
+- `release/8.0-staging`
 - `release/7.0-staging`
 - `release/6.0-staging`
 
@@ -15,6 +16,10 @@ If a library is packable (check for the `<IsPackable>true</IsPackable>` property
 
 When you make a change to a library & ship it during the servicing release, the `ServicingVersion` must be bumped. This property is found in the library's source project. It's also possible that the property is not in that file, in which case you'll need to add it to the library's source project and set it to 1. If the property is already present in your library's source project, just increment the servicing version by 1.
 
+## Optionally ensure all up-stack packages are also produced
+
+If you wish to ensure that every package that references a serviced package is also serviced itself, you can enable validation by setting `ServiceTransitiveDependencies` to true.  This can be done in an individual project, or globally.  When doing this then building the repo, eg: `build libs -allConfigurations` you'll see errors from any project that didn't enable servicing.  Reasons for forcing packages which depend on your package to service are security servicing or removing dependencies.
+
 ## Test your changes
 
 All that's left is to ensure that your changes have worked as expected. To do so, execute the following steps:
@@ -32,11 +37,12 @@ All the servicing change must go through an approval process. You have two ways
 
 - By manually creating your PR using [this template](https://raw.githubusercontent.com/dotnet/runtime/main/.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md).
 - Or by asking the bot to automatically create the servicing PR for you using a merged `main` PR as source. This method requires typing an AzDO backport command as a comment of your merged PR using the format `/backport to release/X.0-staging`. Examples:
--
+
+  - `/backport to release/8.0-staging`
   - `/backport to release/7.0-staging`
   - `/backport to release/6.0-staging`
 
-For both cases, you must:
+For all cases, you must:
 
 - Fill out the template of the PR description.
 - Bring it to the attention of the [engineering lead responsible for the area](~/docs/area-owners.md).