Unity-Technologies · joshpeterson · Jan 1, 2022 · Jan 2, 2022 · Jan 3, 2022 · Jan 3, 2022
diff --git a/.config/dotnet-tools.json b/.config/dotnet-tools.json
@@ -3,19 +3,19 @@
   "isRoot": true,
   "tools": {
     "coverlet.console": {
-      "version": "1.7.2",
+      "version": "3.1.0",
       "commands": [
         "coverlet"
       ]
     },
     "dotnet-reportgenerator-globaltool": {
-      "version": "4.5.8",
+      "version": "5.0.2",
       "commands": [
         "reportgenerator"
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "1.0.0-prerelease.21622.1",
+      "version": "1.0.0-prerelease.22062.1",
       "commands": [
         "xharness"
       ]

diff --git a/.gitignore b/.gitignore
@@ -187,6 +187,7 @@ node_modules/
 *.metaproj.tmp
 bin.localpkg/
 src/mono/wasm/runtime/dotnet.d.ts.sha256
+src/mono/sample/wasm/browser-nextjs/public/
 
 # RIA/Silverlight projects
 Generated_Code/

diff --git a/Directory.Build.props b/Directory.Build.props
@@ -31,6 +31,7 @@
     <TargetArchitecture Condition="'$(TargetArchitecture)' == '' and '$(_hostArch)' == 'arm'">arm</TargetArchitecture>
     <TargetArchitecture Condition="'$(TargetArchitecture)' == '' and '$(_hostArch)' == 'armel'">armel</TargetArchitecture>
     <TargetArchitecture Condition="'$(TargetArchitecture)' == '' and '$(_hostArch)' == 'arm64'">arm64</TargetArchitecture>
+    <TargetArchitecture Condition="'$(TargetArchitecture)' == '' and '$(_hostArch)' == 'loongarch64'">loongarch64</TargetArchitecture>
     <TargetArchitecture Condition="'$(TargetArchitecture)' == '' and '$(_hostArch)' == 's390x'">s390x</TargetArchitecture>
     <TargetArchitecture Condition="'$(TargetArchitecture)' == '' and '$(TargetOS)' == 'Browser'">wasm</TargetArchitecture>
     <TargetArchitecture Condition="'$(TargetArchitecture)' == '' and '$(TargetsMobile)' == 'true'">x64</TargetArchitecture>
@@ -157,26 +158,27 @@
   </PropertyGroup>
 
   <PropertyGroup Label="CalculateRID">
-    <_toolRuntimeRID Condition="'$(CrossBuild)' == 'true'">$(_hostOS.ToLowerInvariant)-$(_hostArch)</_toolRuntimeRID>
-    <_toolRuntimeRID Condition="'$(BuildingInsideVisualStudio)' == 'true'">$(_runtimeOS)-x64</_toolRuntimeRID>
-    <_toolRuntimeRID Condition="'$(_toolRuntimeRID)' == ''">$(_runtimeOS)-$(_hostArch)</_toolRuntimeRID>
+    <_toolsRID Condition="'$(CrossBuild)' == 'true'">$(_hostOS.ToLowerInvariant)-$(_hostArch)</_toolsRID>
+    <_toolsRID Condition="'$(BuildingInsideVisualStudio)' == 'true'">$(_runtimeOS)-x64</_toolsRID>
+    <_toolsRID Condition="'$(_toolsRID)' == ''">$(_runtimeOS)-$(_hostArch)</_toolsRID>
 
     <!-- There are no WebAssembly tools, so use the default ones -->
-    <_toolRuntimeRID Condition="'$(_runtimeOS)' == 'browser'">linux-x64</_toolRuntimeRID>
-    <_toolRuntimeRID Condition="'$(_runtimeOS)' == 'browser' and '$(HostOS)' == 'windows'">win-x64</_toolRuntimeRID>
-    <_toolRuntimeRID Condition="'$(_runtimeOS)' == 'browser' and '$(HostOS)' == 'osx'">osx-x64</_toolRuntimeRID>
+    <_toolsRID Condition="'$(_runtimeOS)' == 'browser'">linux-x64</_toolsRID>
+    <_toolsRID Condition="'$(_runtimeOS)' == 'browser' and '$(HostOS)' == 'windows'">win-x64</_toolsRID>
+    <_toolsRID Condition="'$(_runtimeOS)' == 'browser' and '$(HostOS)' == 'osx'">osx-x64</_toolsRID>
 
     <!-- There are no Android tools, so use the default ones -->
-    <_toolRuntimeRID Condition="'$(_runtimeOS)' == 'android'">linux-x64</_toolRuntimeRID>
-    <_toolRuntimeRID Condition="'$(_runtimeOS)' == 'android' and '$(HostOS)' == 'windows'">win-x64</_toolRuntimeRID>
-    <_toolRuntimeRID Condition="'$(_runtimeOS)' == 'android' and '$(HostOS)' == 'osx'">osx-x64</_toolRuntimeRID>
+    <_toolsRID Condition="'$(_runtimeOS)' == 'android'">linux-x64</_toolsRID>
+    <_toolsRID Condition="'$(_runtimeOS)' == 'android' and '$(HostOS)' == 'windows'">win-x64</_toolsRID>
+    <_toolsRID Condition="'$(_runtimeOS)' == 'android' and '$(HostOS)' == 'osx'">osx-x64</_toolsRID>
 
     <!-- There are no Mac Catalyst, iOS or tvOS tools and it can be built on OSX only, so use that -->
-    <_toolRuntimeRID Condition="'$(_runtimeOS)' == 'maccatalyst' or '$(_runtimeOS)' == 'ios' or '$(_runtimeOS)' == 'iOSSimulator' or '$(_runtimeOS)' == 'tvos' or '$(_runtimeOS)' == 'tvOSSimulator'">osx-x64</_toolRuntimeRID>
+    <_toolsRID Condition="'$(_runtimeOS)' == 'maccatalyst' or '$(_runtimeOS)' == 'ios' or '$(_runtimeOS)' == 'iOSSimulator' or '$(_runtimeOS)' == 'tvos' or '$(_runtimeOS)' == 'tvOSSimulator'">osx-x64</_toolsRID>
 
-    <!-- There are no non-portable builds for Ilasm/Ildasm -->
-    <MicrosoftNetCoreIlasmPackageRuntimeId Condition="'$(PortableBuild)' != 'true' and '$(_portableOS)' == 'linux'">linux-$(_hostArch)</MicrosoftNetCoreIlasmPackageRuntimeId>
-    <MicrosoftNetCoreIlasmPackageRuntimeId Condition="'$(MicrosoftNetCoreIlasmPackageRuntimeId)' == ''">$(_toolRuntimeRID)</MicrosoftNetCoreIlasmPackageRuntimeId>
+    <!-- There are no non-portable builds for Ilasm, Ildasm, ILC etc. -->
+    <ToolsRID Condition="'$(PortableBuild)' != 'true' and '$(_portableOS)' == 'linux'">linux-$(_hostArch)</ToolsRID>
+    <ToolsRID Condition="'$(ToolsRID)' == ''">$(_toolsRID)</ToolsRID>
+    <MicrosoftNetCoreIlasmPackageRuntimeId>$(ToolsRID)</MicrosoftNetCoreIlasmPackageRuntimeId>
 
     <PackageRID>$(_packageOS)-$(TargetArchitecture)</PackageRID>
 

diff --git a/docs/coding-guidelines/interop-guidelines.md b/docs/coding-guidelines/interop-guidelines.md
@@ -166,6 +166,12 @@ Using enums instead of partial, static classes can lead to needing lots of casts
 
 When defining the P/Invoke signatures and structs, we follow the guidelines in the [interop best practices documentation](https://docs.microsoft.com/en-us/dotnet/standard/native-interop/best-practices).
 
+The runtime repo makes use of [source-generated p/invokes](../design/features/source-generator-pinvokes.md) whenever possible (see [the compatibility doc](../design/libraries/DllImportGenerator/Compatibility.md) for unsupported scenarios). Methods should be marked `GeneratedDllImport` and be `static` and `partial`.
+
+If implicit framework references are disabled (as is the case for most libraries projects), explicit references to the below are required for marshalling arrays:
+  - `System.Memory`
+  - `System.Runtime.CompilerServices.Unsafe`
+
 ## UNIX shims
 
 Often, various UNIX flavors offer the same API from the point-of-view of compatibility with C/C++ source code, but they do not have the same ABI. e.g. Fields can be laid out differently, constants can have different numeric values, exports can be named differently, etc. There are not only differences between operating systems (Mac OS X vs. Ubuntu vs. FreeBSD), but also differences related to the underlying processor architecture (x64 vs. x86 vs. ARM).
@@ -174,6 +180,8 @@ This leaves us with a situation where we can't write portable P/Invoke declarati
 
 To address this, we're moving to a model where all UNIX interop from dotnet/runtime starts with a P/Invoke to a C++ lib written specifically for dotnet/runtime. These libs -- System.*.Native.so (aka "shims") -- are intended to be very thin layers over underlying platform libraries. Generally, they are not there to add any significant abstraction, but to create a stable ABI such that the same IL assembly can work across UNIX flavors.
 
+The System.Native shims are a private implementation detail of the Microsoft.NETCore.App shared framework and are intended only for use by code inside of the shared framework. Calling into the shims from external to Microsoft.NETCore.App has similar risks to using private reflection, with no guarantees from version to version or even patch to patch of stable exports. Assemblies that ship outside of the shared framework (e.g. Microsoft.Extensions.*) must not directly access the shims.
+
 Guidelines for shim C++ API:
 
 - Keep them as "thin"/1:1 as possible.

diff --git a/docs/design/mono/debugger.md b/docs/design/mono/debugger.md
@@ -18,4 +18,11 @@ Web Assembly Debugger supports usage of following attributes:
   - Stepping In/Over: results in an additional stepping need to proceed to the next line.<br><br>
 - __System.Diagnostics.DebuggerDisplay__
 - __System.Diagnostics.DebuggerTypeProxy__
-- ...
+- __System.Diagnostics.DebuggerBrowsable__ ([doc](https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.debuggerbrowsableattribute?view=net-6.0))
+   - Collapsed - displayed normally.
+   - RootHidden:
+      - Simple type - not displayed in the debugger window.
+      - Collection / Array - the values of a collection are displayed in a flat view, using  the naming convention: *rootName[idx]*.
+
+   - Never - not displayed in the debugger window.
+
diff --git a/docs/workflow/Codespaces.md b/docs/workflow/Codespaces.md
@@ -5,13 +5,11 @@ Codespaces allows you to develop in a Docker container running in the cloud. You
 
 dotnet/runtime runs a nightly GitHub Action to build the latest code in the repo. This allows you to immediately start developing and testing after creating a codespace without having to build the whole repo. When the machine is created, it will have built the repo using the code as of 6 AM UTC that morning.
 
-**NOTE**: In order to use a prebuilt codespace, when you create your machine be sure to select an **`8 core`** machine.
-
 1. From https://github.com/dotnet/runtime, drop-down the `Code` button and select the `Codespaces` tab.
 
 ![New codespace button](https://docs.github.com/assets/images/help/codespaces/new-codespace-button.png)
 
-2. Select `8-core` for the Machine type. This will ensure you get a "pre built" image.
+2. Select the Machine type. For dotnet/runtime, it is recommended to select at least a `4-core` machine. You can also verify that a "Prebuild" is ready.
 
 ![Codespace machine size](./codespace-machine-size.png)
 

diff --git a/docs/workflow/codespace-machine-size.png b/docs/workflow/codespace-machine-size.png
diff --git a/docs/workflow/debugging/coreclr/debugging-aot-compilers.md b/docs/workflow/debugging/coreclr/debugging-aot-compilers.md
@@ -19,7 +19,7 @@ Built in debugging aids in the managed compilers
 ---------------------------------
 
 - When debugging a multi-threaded component of the compiler and not investigating a multi-threading issue itself, it is generally advisable to disable the use of multiple threads.
-To do this use the `--parallelism 1` switch (for crossgen2) or `--singlethreaded` (for ILC) to specify that the maximum parallelism of the process shall be 1.
+To do this use the `--parallelism 1` switch to specify that the maximum parallelism of the process shall be 1.
 
 - When debugging the behavior of compiling a single method, the compiler may be instructed to only compile a single method. This is done via the various --singlemethod options
 
@@ -172,3 +172,7 @@ devenv /debugexe C:\git2\runtime\.dotnet\dotnet.exe "c:\git2\runtime\artifacts\t
 ```
 
 This will launch the Visual Studio debugger, with a solution setup for debugging the dotnet.exe process. By default this solution will debug the native code of the process only. To debug the managed components, edit the properties on the solution and set the `Debugger Type` to `Managed (.NET Core, .NET 5+)` or `Mixed (.NET Core, .NET 5+)`.
+
+# Debugging compilation graph
+
+The AOT compilation is driven by a dependency graph. If you need to troubleshoot the dependency graph (to figure out why something was or wasn't generated) you can follow [this guide](debuging-compiler-dependency-analysis.md)
diff --git a/docs/workflow/debugging/coreclr/debuging-compiler-dependency-analysis.md b/docs/workflow/debugging/coreclr/debuging-compiler-dependency-analysis.md
@@ -0,0 +1,47 @@
+Debugging Compiler Dependency Analysis
+============================
+
+The general technique is to identify what node is missing from the graph or is erroneously present in the graph, and change the dependency analysis logic to adjust the graph. This document describes the various ways of debugging to identify what's happening.
+
+Analysis techniques for the dependency graph.
+1. Use the DependencyGraphViewer tool (if running on Windows). This tool is located in `src/coreclr/tools/aot/DependencyGraphViewer`
+  - This is the only convenient way to examine the graph while also simultaneously debugging the compiler.
+  - While this is currently Windows only due to use of WinForms, it would be fairly straightforward to make a command line based tool.
+  - Dependency graph does not support multiple simultaneous logging facilities, so make sure that you do not set IlcGenerateDgmlFile or invoke ILCompiler with the DGML generation turned on.
+2. Pass command line switches to the compiler to generate a dependency graph dgml file. This will produce the same data as is viewable in the viewer tool, but in a textual xml format.
+  - Future efforts may make the xml file loadable by the viewer tool.
+3. Instrument the compiler dependency analysis. (This may be necessary in cases where the viewer is unable to provide sufficient information about why the graph is structured as it is.)
+
+DependencyGraphViewer
+====================================
+
+This application allows viewing the dependency graph produced by the AOT compilation.
+
+Usage instructions:
+1. Launch the process as an administrator
+2. Run the compiler
+- The compiler can be run to completion, or stopped.
+3. Explore through the graph
+
+# Graphs View #
+- Choose one of the graphs that appears in the Dependency Graphs view to explore. As compilers execute, new graphs will automatically appear here.
+- The set of graphs loaded into the process is limited by available memory space. To clear the used memory, close all windows of the application.
+
+# Graph View #
+- In the Dependency Graph view, enter a regular expression in the text box, and then press ""Filter"". This will display a list of the nodes in the graph which have names which match the regular expression.
+- Commonly, if there is a object file symbol associated with the node it should be used as part of the regular expression. See the various implementations of GetName in the compiler for naming behavior.
+- Additionally, the event source marking mode assigns an Id to each node, and that is found as the mark object on the node, so if a specific id is known, just type that in, and it will appear in the window. (This is for use when using this tool in parallel with debugging the compiler.
+
+# Single Node Exploration #
+Once the interesting node(s) have been identified in the dependency graph window, select one of them, and then press Explore.
+  - In the Node Explorer window, the Dependent nodes (the ones which dependend on the current node are the nodes displayed above, and the Dependee nodes (the nodes that this node depends on) are displayed below. Each node in the list is paired with a textual reason as to why that edge in the graph exists.
+  - Select a node to explore further and press the corresponding button to make it happen.
+
+WhyDGML
+=======
+This tool can be used to visualize paths from a node of interest to the roots. To use it, pass command line option to the compiler to generate the DGML file (`--dgmllog name_of_output_file`) and then use this tool to find the path to the root. If you're looking at an optimized NativeAOT compilation, `--scandgmllog` might be preferable since it will have more details.
+The input to the tool is the DGML file and name of a node of interest. The output is the list of reasons why that node was included.
+
+This tool located in folder `src/coreclr/tools/aot/WhyDgml`
+
+See https://github.com/dotnet/corert/pull/7962 for example of usage and output.
diff --git a/docs/workflow/requirements/freebsd-requirements.md b/docs/workflow/requirements/freebsd-requirements.md
@@ -1,13 +1,12 @@
-Requirements to build dotnet/runtime on FreeBSD
+Requirements to build and run dotnet/runtime on FreeBSD
 =====================
 
-This guide will walk you through the requirements needed to build dotnet/runtime on FreeBSD. We'll start by showing how to set up your environment from scratch.
+This guide will walk you through the requirements needed to build and run dotnet/runtime on FreeBSD. We'll start by showing how to set up your environment from scratch.
 Since there is no official build and FreeBSD package, native build on FreeBSD is not trivial. There are generally three options, sorted by ease of use:
 - cross-compile on Linux using Docker
 - cross-compile on Linux using Toolchain
 - build on FreeBSD
 
-
 Environment
 ===========
 
@@ -65,3 +64,46 @@ sudo pkg install --yes libunwind icu libinotify lttng-ust krb5 cmake openssl nin
 Additionally, working dotnet cli with SDK is needed. On other platforms this would be downloaded automatically during build but it is not currently available for FreeBSD.
 It needs to be built once on supported platform or obtained via community resources.
 
+Running on FreeBSD
+-------------------
+Install the following packages:
+- icu
+- libunwind
+- lttng-ust (optional, debug support)
+- krb5
+- openssl (optional, SSL support)
+- libinotify
+- terminfo-db (optional, terminal colors)
+
+The lines to install all the packages above using package manager.
+
+```sh
+sudo pkg install --yes libunwind icu libinotify lttng-ust krb5 openssl terminfo-db
+```
+
+Extract the SDK:
+The canonical location for the SDK is `/usr/share/dotnet`
+
+"VERSION" is the SDK version being unpacked.
+
+```sh
+sudo mkdir /usr/share/dotnet
+tar xf /tmp/dotnet-sdk-VERSION-freebsd-x64.tar.gz -C /usr/share/dotnet/
+```
+
+NuGet Packages:
+The canonical location for the NuGet packages is `/var/cache/nuget`
+
+"VERSION" is the same version as the SDK from above.
+
+- Microsoft.NETCore.App.Host.freebsd-x64.VERSION.nupkg
+- Microsoft.NETCore.App.Runtime.freebsd-x64.VERSION.nupkg
+- Microsoft.AspNetCore.App.Runtime.freebsd-x64.VERSION.nupkg
+
+Add the following line to any `NuGet.config` you are using under the `<packageSources>` section:
+
+```xml
+<add key="local" value="/var/cache/nuget" />
+```
+
+Finally, either add `/usr/share/dotnet` to your PATH or create a symbolic for `/usr/share/dotnet/dotnet`
diff --git a/eng/CodeAnalysis.src.globalconfig b/eng/CodeAnalysis.src.globalconfig
@@ -1444,7 +1444,7 @@ dotnet_diagnostic.IDE0057.severity = suggestion
 dotnet_diagnostic.IDE0058.severity = silent
 
 # IDE0059: Unnecessary assignment of a value
-dotnet_diagnostic.IDE0059.severity = suggestion
+dotnet_diagnostic.IDE0059.severity = warning
 
 # IDE0060: Remove unused parameter
 dotnet_diagnostic.IDE0060.severity = silent

diff --git a/eng/Subsets.props b/eng/Subsets.props
@@ -243,7 +243,7 @@
     <ProjectToBuild Include="$(CoreClrProjectRoot)nativeaot\BuildIntegration\BuildIntegration.proj" Category="clr" Condition="'$(NativeAotSupported)' == 'true'" />
 
     <ProjectToBuild Condition="'$(TargetArchitecture)' != 'x64' and '$(BuildArchitecture)' == 'x64'" Include="$(CoreClrProjectRoot)tools\aot\crossgen2\crossgen2_crossarch.csproj" Category="clr" />
-    <ProjectToBuild Include="$(CoreClrProjectRoot)tools\aot\ILCompiler.TypeSystem.ReadyToRun.Tests\ILCompiler.TypeSystem.ReadyToRun.Tests.csproj"
+    <ProjectToBuild Include="$(CoreClrProjectRoot)tools\aot\ILCompiler.TypeSystem.Tests\ILCompiler.TypeSystem.Tests.csproj"
       Test="true" Category="clr" Condition="'$(DotNetBuildFromSource)' != 'true'"/>
     <ProjectToBuild Include="$(CoreClrProjectRoot)tools\aot\ILCompiler.Compiler.Tests\ILCompiler.Compiler.Tests.csproj"
       Test="true" Category="clr" Condition="'$(DotNetBuildFromSource)' != 'true' and '$(NativeAotSupported)' == 'true'"/>