Merge branch 'main' into combined_limit

Author: jkotas

.devcontainer/Dockerfile

@@ -5,12 +5,19 @@
 ARG VARIANT="6.0-jammy"
 FROM mcr.microsoft.com/devcontainers/dotnet:0-${VARIANT}
 
+# Set up machine requirements to build the repo and the gh CLI
+# Clang-16 up is required but Ubuntu 22.04 comes with clang-14 highest, so add clang-18 sources
+RUN apt-get update \
+    && wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add - \
+    && apt-get install software-properties-common -y \
+    && add-apt-repository "deb http://apt.llvm.org/$(lsb_release -s -c)/ llvm-toolchain-$(lsb_release -s -c)-18 main" -y \
+    && apt-get update \
+    && apt-get install clang-18 -y
+
 # Set up machine requirements to build the repo and the gh CLI
 RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
     && apt-get -y install --no-install-recommends \
         cmake \
-        llvm \
-        clang \
         build-essential \
         python3 \
         curl \

.devcontainer/wasm-multiThreaded/Dockerfile

@@ -5,12 +5,19 @@
 ARG VARIANT="6.0-jammy"
 FROM mcr.microsoft.com/devcontainers/dotnet:0-${VARIANT}
 
+# Set up machine requirements to build the repo and the gh CLI
+# Clang-16 up is required but Ubuntu 22.04 comes with clang-14 highest, so add clang-18 sources
+RUN apt-get update \
+    && wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add - \
+    && apt-get install software-properties-common -y \
+    && add-apt-repository "deb http://apt.llvm.org/$(lsb_release -s -c)/ llvm-toolchain-$(lsb_release -s -c)-18 main" -y \
+    && apt-get update \
+    && apt-get install clang-18 -y
+
 # Set up machine requirements to build the repo and the gh CLI
 RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
     && apt-get -y install --no-install-recommends \
         cmake \
-        llvm \
-        clang \
         build-essential \
         python3 \
         curl \

.devcontainer/wasm/Dockerfile

@@ -6,11 +6,17 @@ ARG VARIANT="6.0-jammy"
 FROM mcr.microsoft.com/devcontainers/dotnet:0-${VARIANT}
 
 # Set up machine requirements to build the repo and the gh CLI
+# Clang-16 up is required but Ubuntu 22.04 comes with clang-14 highest, so add clang-18 sources
+RUN apt-get update \
+    && wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add - \
+    && apt-get install software-properties-common -y \
+    && add-apt-repository "deb http://apt.llvm.org/$(lsb_release -s -c)/ llvm-toolchain-$(lsb_release -s -c)-18 main" -y \
+    && apt-get update \
+    && apt-get install clang-18 -y
+
 RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
     && apt-get -y install --no-install-recommends \
         cmake \
-        llvm \
-        clang \
         build-essential \
         python3 \
         curl \

Directory.Build.props

@@ -388,7 +388,7 @@
     <Features>strict;nullablePublicOnly</Features>
     <TreatWarningsAsErrors Condition="'$(TreatWarningsAsErrors)' == ''">true</TreatWarningsAsErrors>
     <!-- Warnings to always disable -->
-    <NoWarn>$(NoWarn),CS8969</NoWarn>
+    <NoWarn>$(NoWarn);CS8500;CS8969</NoWarn>
     <!-- Always pass portable to override arcade sdk which uses embedded for local builds -->
     <DebugType>portable</DebugType>
     <KeepNativeSymbols Condition="'$(KeepNativeSymbols)' == '' and '$(DotNetBuildSourceOnly)' == 'true'">true</KeepNativeSymbols>

Directory.Build.targets

@@ -97,18 +97,10 @@
     <Error Text="The passed-in TargetOS property value '$(TargetOS)' must be lowercase." />
   </Target>
 
-  <ItemDefinitionGroup>
-    <TargetPathWithTargetPlatformMoniker>
-      <IsReferenceAssemblyProject>$(IsReferenceAssemblyProject)</IsReferenceAssemblyProject>
-    </TargetPathWithTargetPlatformMoniker>
-  </ItemDefinitionGroup>
-
-  <Target Name="ValidateReferenceAssemblyProjectReferencesAndTargetFramework"
-          AfterTargets="ResolveReferences"
+  <Target Name="ValidateReferenceAssemblyProjectTargetFramework"
+          BeforeTargets="CoreCompile"
           Condition="'$(IsReferenceAssemblyProject)' == 'true' and
                      '$(SkipValidateReferenceAssemblyProjectReferences)' != 'true'">
-    <Error Text="Reference assemblies must only reference other reference assemblies and '%(ReferencePath.ProjectReferenceOriginalItemSpec)' is not a reference assembly project and does not set 'ProduceReferenceAssembly'."
-           Condition="'%(ReferencePath.ReferenceSourceTarget)' == 'ProjectReference' and '%(ReferencePath.IsReferenceAssemblyProject)' != 'true' and '%(ReferencePath.ReferenceAssembly)' == ''" />
     <Error Text="Reference assemblies must be TargetPlatform agnostic. $(MSBuildProjectName) incorrectly targets $(TargetFramework), platform: $(TargetPlatformIdentifier)."
            Condition="'$(TargetPlatformIdentifier)' != ''" />
   </Target>

THIRD-PARTY-NOTICES.TXT

@@ -66,38 +66,6 @@ shall not be used in advertising or otherwise to promote the sale,
 use or other dealings in these Data Files or Software without prior
 written authorization of the copyright holder.
 
-License notice for Zlib
------------------------
-
-https://github.com/madler/zlib
-https://zlib.net/zlib_license.html
-
-/* zlib.h -- interface of the 'zlib' general purpose compression library
-  version 1.3.1, January 22nd, 2024
-
-  Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler
-
-  This software is provided 'as-is', without any express or implied
-  warranty.  In no event will the authors be held liable for any damages
-  arising from the use of this software.
-
-  Permission is granted to anyone to use this software for any purpose,
-  including commercial applications, and to alter it and redistribute it
-  freely, subject to the following restrictions:
-
-  1. The origin of this software must not be misrepresented; you must not
-     claim that you wrote the original software. If you use this software
-     in a product, an acknowledgment in the product documentation would be
-     appreciated but is not required.
-  2. Altered source versions must be plainly marked as such, and must not be
-     misrepresented as being the original software.
-  3. This notice may not be removed or altered from any source distribution.
-
-  Jean-loup Gailly        Mark Adler
-  jloup@gzip.org          madler@alumni.caltech.edu
-
-*/
-
 License notice for zlib-ng
 -----------------------
 

docs/coding-guidelines/api-guidelines/nullability.md

@@ -67,7 +67,7 @@ However, for existing virtual APIs that do not have any such strong guarantee do
 4. How common is it in the case of (3) for such invocations to then dereference the result rather than passing it off to something else that accepts a `T?`?
 
 `Object.ToString` is arguably the most extreme case.  Answering the above questions:
-1. It is fairly easy in any reasonably-sized code base to find cases, intentional or otherwise, where `ToString` returns `null` in some cases (we've found examples in dotnet/corefx, dotnet/roslyn, NuGet/NuGet.Client, dotnet/aspnetcore, and so on).  One of the most prevalent conditions for this are types that just return the value in a string field which may contain its default value of `null`, and in particular for structs where a ctor may not have even had a chance to run and validate an input.  Guidance in the docs suggests that `ToString` shouldn't return `null` or `string.Empty`, but even the docs don't follow its own guidance.
+1. It is fairly easy in any reasonably-sized code base to find cases, intentional or otherwise, where `ToString` returns `null` in some cases (we've found examples in dotnet/runtime, dotnet/roslyn, NuGet/NuGet.Client, dotnet/aspnetcore, and so on).  One of the most prevalent conditions for this are types that just return the value in a string field which may contain its default value of `null`, and in particular for structs where a ctor may not have even had a chance to run and validate an input.  Guidance in the docs suggests that `ToString` shouldn't return `null` or `string.Empty`, but even the docs don't follow its own guidance.
 2. Thousands upon thousands of types we don't control override this method today.
 3. It's common for helper routines to invoke via the base `object.ToString`, but many `ToString` uses are actually on derived types.  This is particularly true when working in a code base that both defines a type and consumes its `ToString`.
 4. Based on examination of several large code bases, we believe it to be relatively rare that the result of an `Object.ToString` call (made on the base) to be directly dereferenced.  It's much more common to pass it to another method that accepts `string?`, such as `String.Concat`, `String.Format`, `Console.WriteLine`, logging utilities, and so on.  And while we advocate that `ToString` results shouldn't be assumed to be in a particular machine-readable format and parsed, it's certainly the case that code bases do, such as using `Substring` on the result, but in such cases, the caller needs to understand the format of what's being rendered, which generally means they're working with a derived type rather than calling through the base `Object.ToString`.

docs/design/coreclr/botr/method-descriptor.md

@@ -85,7 +85,9 @@ DWORD MethodDesc::GetAttrs()
 Method Slots
 ------------
 
-Each MethodDesc has a slot, which contains the entry point of the method. The slot and entry point must exist for all methods, even the ones that never run like abstract methods. There are multiple places in the runtime that depend on the 1:1 mapping between entry points and MethodDescs, making this relationship an invariant.
+Each MethodDesc has a slot, which contains the current entry point of the method. The slot must exist for all methods, even the ones that never run like abstract methods. There are multiple places in the runtime that depend on mapping between entry points and MethodDescs.
+
+Each MethodDesc logically has an entry point, but we do not allocate these eagerly at MethodDesc creation time. The invariant is that once the method is identified as a method to run, or is used in virtual overriding, we will allocate the entrypoint.
 
 The slot is either in MethodTable or in MethodDesc itself. The location of the slot is determined by `mdcHasNonVtableSlot` bit on MethodDesc.
 
@@ -185,8 +187,6 @@ The target of the temporary entry point is a PreStub, which is a special kind of
 
 The **stable entry point** is either the native code or the precode. The **native code** is either jitted code or code saved in NGen image. It is common to talk about jitted code when we actually mean native code.
 
-Temporary entry points are never saved into NGen images. All entry points in NGen images are stable entry points that are never changed. It is an important optimization that reduced private working set.
-
 ![Figure 2](images/methoddesc-fig2.png)
 
 Figure 2 Entry Point State Diagram
@@ -208,6 +208,7 @@ The methods to get callable entry points from MethodDesc are:
 
 - `MethodDesc::GetSingleCallableAddrOfCode`
 - `MethodDesc::GetMultiCallableAddrOfCode`
+- `MethodDesc::TryGetMultiCallableAddrOfCode`
 - `MethodDesc::GetSingleCallableAddrOfVirtualizedCode`
 - `MethodDesc::GetMultiCallableAddrOfVirtualizedCode`
 
@@ -220,7 +221,7 @@ The type of precode has to be cheaply computable from the instruction sequence.
 
 **StubPrecode**
 
-StubPrecode is the basic precode type. It loads MethodDesc into a scratch register and then jumps. It must be implemented for precodes to work. It is used as fallback when no other specialized precode type is available.
+StubPrecode is the basic precode type. It loads MethodDesc into a scratch register<sup>2</sup> and then jumps. It must be implemented for precodes to work. It is used as fallback when no other specialized precode type is available.
 
 All other precodes types are optional optimizations that the platform specific files turn on via HAS\_XXX\_PRECODE defines.
 
@@ -236,7 +237,7 @@ StubPrecode looks like this on x86:
 
 FixupPrecode is used when the final target does not require MethodDesc in scratch register<sup>2</sup>. The FixupPrecode saves a few cycles by avoiding loading MethodDesc into the scratch register.
 
-The most common usage of FixupPrecode is for method fixups in NGen images.
+Most stubs used are the more efficient form, we currently can use this form for everything but interop methods when a specialized form of Precode is not required.
 
 The initial state of the FixupPrecode on x86:
 
@@ -254,67 +255,6 @@ Once it has been patched to point to final target:
 
 <sup>2</sup> Passing MethodDesc in scratch register is sometimes referred to as **MethodDesc Calling Convention**.
 
-**FixupPrecode chunks**
-
-FixupPrecode chunk is a space efficient representation of multiple FixupPrecodes. It mirrors the idea of MethodDescChunk by hoisting the similar MethodDesc pointers from multiple FixupPrecodes to a shared area.
-
-The FixupPrecode chunk saves space and improves code density of the precodes. The code density improvement from FixupPrecode chunks resulted in 1% - 2% gain in big server scenarios on x64.
-
-The FixupPrecode chunks looks like this on x86:
-
-	jmp Target2
-	pop edi // dummy instruction that marks the type of the precode
-	db MethodDescChunkIndex
-	db 2 (PrecodeChunkIndex)
-
-	jmp Target1
-	pop edi
-	db MethodDescChunkIndex
-	db 1 (PrecodeChunkIndex)
-
-	jmp Target0
-	pop edi
-	db MethodDescChunkIndex
-	db 0 (PrecodeChunkIndex)
-
-	dw pMethodDescBase
-
-One FixupPrecode chunk corresponds to one MethodDescChunk. There is no 1:1 mapping between the FixupPrecodes in the chunk and MethodDescs in MethodDescChunk though. Each FixupPrecode has index of the method it belongs to. It allows allocating the FixupPrecode in the chunk only for methods that need it.
-
-**Compact entry points**
-
-Compact entry point is a space efficient implementation of temporary entry points.
-
-Temporary entry points implemented using StubPrecode or FixupPrecode can be patched to point to the actual code. Jitted code can call temporary entry point directly. The temporary entry point can be multicallable entry points in this case.
-
-Compact entry points cannot be patched to point to the actual code. Jitted code cannot call them directly. They are trading off speed for size. Calls to these entry points are indirected via slots in a table (FuncPtrStubs) that are patched to point to the actual entry point eventually. A request for a multicallable entry point allocates a StubPrecode or FixupPrecode on demand in this case.
-
-The raw speed difference is the cost of an indirect call for a compact entry point vs. the cost of one direct call and one direct jump on the given platform. The later used to be faster by a few percent in large server scenario since it can be predicted by the hardware better (2005). It is not always the case on current (2015) hardware.
-
-The compact entry points have been historically implemented on x86 only. Their additional complexity, space vs. speed trade-off and hardware advancements made them unjustified on other platforms.
-
-The compact entry point on x86 looks like this:
-
-	entrypoint0:
-	 mov al,0
-	 jmp short Dispatch
-
-	entrypoint1:
-	 mov al,1
-	 jmp short Dispatch
-
-	entrypoint2:
-	 mov al,2
-	 jmp short Dispatch
-
-	Dispatch:
-	 movzx eax,al
-	 shl eax, 3
-	 add eax, pBaseMD
-	 jmp PreStub
-
-The allocation of temporary entry points always tries to pick the smallest temporary entry point from the available choices. For example, a single compact entry point is bigger than a single StubPrecode on x86. The StubPrecode will be preferred over the compact entry point in this case. The allocation of the precode for a stable entry point will try to reuse an allocated temporary entry point precode if one exists of the matching type.
-
 **ThisPtrRetBufPrecode**
 
 ThisPtrRetBufPrecode is used to switch a return buffer and the this pointer for open instance delegates returning valuetypes. It is used to convert the calling convention of MyValueType Bar(Foo x) to the calling convention of MyValueType Foo::Bar().

docs/design/coreclr/jit/JitOptimizerTodoAssessment.md

@@ -49,7 +49,7 @@ the code quality improvements, though most have issues associated with them.
 We may well be able to find some additional benchmarks or real-world-code with some looking,
 though it may be the case that current performance-sensitive code avoids structs.
 
-There's also work going on in corefx to use `Span<T>` more broadly.  We should
+There's also work going on to use `Span<T>` more broadly.  We should
 make sure we are expanding our span benchmarks appropriately to track and
 respond to any particular issues that come out of that work.
 

docs/design/coreclr/jit/object-stack-allocation.md

@@ -83,7 +83,7 @@ with version reseliency.
 **Pros:**
 * ILLInk can afford to spend more time for escape analysis.
 * For self-contained apps, ILLink has access to all of application's code and can do full interprocedural analysis.
-* ILLink is already a part of System.Private.CoreLib and CoreFX build toolchain so the assemblies built there can benefit
+* ILLink is already a part of System.Private.CoreLib and core libraries build toolchain so the assemblies built there can benefit
 from this.
 
 **Cons:**