Merge branch 'main' into cmake-3.26

Author: jkoritzinsky

.config/dotnet-tools.json

@@ -15,7 +15,7 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "11.0.0-prerelease.25578.2",
+      "version": "11.0.0-prerelease.25601.7",
       "commands": [
         "xharness"
       ]

.devcontainer/android/devcontainer.json

@@ -55,8 +55,7 @@
 	// This allows developers to just use 'dotnet build' on the command-line, and the local dotnet version will be used.
     // Add the Android SDK tooling and emulator to the path.
 	"remoteEnv": {
-		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:ANDROID_SDK_ROOT}/cmdline-tools/cmdline-tools/bin:${containerEnv:ANDROID_SDK_ROOT}/emulator:${containerEnv:ANDROID_SDK_ROOT}/platform-tools:${containerEnv:PATH}",
-		"DOTNET_MULTILEVEL_LOOKUP": "0"
+		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:ANDROID_SDK_ROOT}/cmdline-tools/cmdline-tools/bin:${containerEnv:ANDROID_SDK_ROOT}/emulator:${containerEnv:ANDROID_SDK_ROOT}/platform-tools:${containerEnv:PATH}"
 	},
 
 	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.

.devcontainer/devcontainer.json

@@ -40,8 +40,7 @@
 	// Add the locally installed dotnet to the path to ensure that it is activated
 	// This allows developers to just use 'dotnet build' on the command-line, and the local dotnet version will be used.
 	"remoteEnv": {
-		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:PATH}",
-		"DOTNET_MULTILEVEL_LOOKUP": "0"
+		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:PATH}"
 	},
 
 	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.

.devcontainer/libraries/devcontainer.json

@@ -46,8 +46,7 @@
 	// Add the locally installed dotnet to the path to ensure that it is activated
 	// This allows developers to just use 'dotnet build' on the command-line, and the local dotnet version will be used.
 	"remoteEnv": {
-		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:PATH}",
-		"DOTNET_MULTILEVEL_LOOKUP": "0"
+		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:PATH}"
 	},
 
 	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.

.devcontainer/wasm-multiThreaded/devcontainer.json

@@ -47,8 +47,7 @@
 	// This allows developers to just use 'dotnet build' on the command-line, and the local dotnet version will be used.
 	// Add the global tools dir to the PATH so that globally installed tools will work
 	"remoteEnv": {
-		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerWorkspaceFolder}/.dotnet-tools-global:${containerEnv:PATH}",
-		"DOTNET_MULTILEVEL_LOOKUP": "0",
+		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerWorkspaceFolder}/.dotnet-tools-global:${containerEnv:PATH}"
 	},
 
 	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
@@ -58,7 +57,7 @@
 	"forwardPorts": [8000],
 	"portsAttributes": {
 		"8000": {
-			"label": "mono wasm samples (8000)",
+			"label": "mono wasm samples (8000)"
 		}
 	}
 }

.devcontainer/wasm/devcontainer.json

@@ -47,8 +47,7 @@
 	// This allows developers to just use 'dotnet build' on the command-line, and the local dotnet version will be used.
 	// Add the global tools dir to the PATH so that globally installed tools will work
 	"remoteEnv": {
-		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerWorkspaceFolder}/.dotnet-tools-global:${containerEnv:PATH}",
-		"DOTNET_MULTILEVEL_LOOKUP": "0",
+		"PATH": "${containerWorkspaceFolder}/.dotnet:${containerWorkspaceFolder}/.dotnet-tools-global:${containerEnv:PATH}"
 	},
 
 	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
@@ -58,7 +57,7 @@
 	"forwardPorts": [8000],
 	"portsAttributes": {
 		"8000": {
-			"label": "mono wasm samples (8000)",
+			"label": "mono wasm samples (8000)"
 		}
 	}
 }

.gitattributes

@@ -81,3 +81,4 @@ src/tests/JIT/Performance/CodeQuality/BenchmarksGame/reverse-complement/revcomp-
 src/tests/JIT/Performance/CodeQuality/BenchmarksGame/k-nucleotide/knucleotide-input.txt text eol=lf
 src/tests/JIT/Performance/CodeQuality/BenchmarksGame/k-nucleotide/knucleotide-input-big.txt text eol=lf
 src/mono/browser/runtime/dotnet.d.ts text eol=lf
+src/native/corehost/browserhost/loader/dotnet.d.ts text eol=lf

docs/design/coreclr/botr/README.md

@@ -30,6 +30,7 @@ Below is a table of contents.
 - [Mixed Mode Assemblies](mixed-mode.md)
 - [Guide For Porting](guide-for-porting.md)
 - [Vectors and Intrinsics](vectors-and-intrinsics.md)
+- [Runtime Async Codegen](runtime-async-codegen.md)
 
 
 It may be possible that this table is not complete.  You can get a complete list

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

@@ -678,3 +678,19 @@ MyStruct Test2()
 	return default;
 }
 ```
+
+# Interpreter ABI details
+
+The interpreter data stack is separately allocated from the normal "thread" stack, and it grows UP. The interpreter execution control stack is allocated on the "thread" stack, as a series of `InterpMethodContextFrame` values that are linked in a singly linked list onto an `InterpreterFrame` which is placed onto the Frame chain of the thread. `InterpMethodContextFrame` structures are always allocated in descending order so that a callee method's associated `InterpMethodContextFrame` is always located lower in memory compared to its caller or the containing `InterpreterFrame`.
+
+The base stack pointer within a method never changes, but when a function is called in the interpreter it will have a stack pointer which is associated with the set of arguments passed. In effect argument passing is done by giving a portion of the temporary args space of the caller function to the callee.
+
+All instructions and GC that address the stack pointer are relative to the current stack pointer, which does not move. This requires that implementations of the localloc instruction actually allocate the memory on the heap, and localloc'd memory is not actually tied to the data stack in any way.
+
+The stack pointer in all interpreter functions is always aligned on a `INTERP_STACK_ALIGNMENT` boundary. Currently this is a 16 byte alignment requirement.
+
+The stack elements are always aligned to at least `INTERP_STACK_SLOT_SIZE` and never more than `INTERP_STACK_ALIGNMENT` Given that today's implementation sets `INTERP_STACK_SLOT_SIZE` to 8 and `INTERP_STACK_ALIGNMENT` to 16, this implies all data on the stack is either aligned at an 8 or 16 byte alignment.
+
+Primitive types smaller than 4 bytes are always zero or sign extended to 4 bytes when on the stack.
+
+When a function is async it will have a continuation return. This return is not done using the data stack, but instead is done by setting the Continuation field in the `InterpreterFrame`. Thunks are responsible for setting/resetting this value as we enter/leave code compiled by the JIT.

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

@@ -872,7 +872,7 @@ enum ReadyToRunHelper
     READYTORUN_HELPER_MemCpy                    = 0x41,
 
     // Get string handle lazily
-    READYTORUN_HELPER_GetString                 = 0x50,
+    READYTORUN_HELPER_GetString                 = 0x50, // Unused since READYTORUN_MAJOR_VERSION 17.0
 
     // Used by /Tuning for Profile optimizations
     READYTORUN_HELPER_LogMethodEnter            = 0x51, // Unused since READYTORUN_MAJOR_VERSION 10.0