* update runtime repo to produce SBOM after signing artifacts
* disable SBOM autogeneration for prepare signed artifacts leg
* disable SBOM autogeneration for prepare signed artifacts leg
* disable SBOM autogeneration for prepare signed artifacts leg
* set the verbosity level of the logging output to Debug
* remove unnecessary parameters
* remove verbosity parameter
* remove verbosity parameter
* remove verbosity parameter
---------
Co-authored-by: Haruna Ogweda <harunaogweda@microsoft.com>
Microsoft.SourceBuild.Intermediate.sdk , Microsoft.DotNet.ApiCompat.Task
From Version 9.0.103-servicing.25065.25 -> To Version 9.0.104-servicing.25111.36
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
Backport of https://github.com/dotnet/runtime/pull/113287
This change will revert to the hashtable container used for the generic instance cache in .NET 8.0 to address a performance regression introduced by changing to a different container in 9. Also improves the hash function used for the cache (the existing one was suboptimal.)
Co-authored-by: Katelyn Gadd <kg@luminance.org>
* Update dependencies from https://github.com/dotnet/hotreload-utils build 20250210.2
Microsoft.DotNet.HotReload.Utils.Generator.BuildTool
From Version 9.0.0-alpha.0.25077.3 -> To Version 9.0.0-alpha.0.25110.2
* Update dependencies from https://github.com/dotnet/hotreload-utils build 20250213.2
Microsoft.DotNet.HotReload.Utils.Generator.BuildTool
From Version 9.0.0-alpha.0.25077.3 -> To Version 9.0.0-alpha.0.25113.2
* Update dependencies from https://github.com/dotnet/hotreload-utils build 20250224.3
Microsoft.DotNet.HotReload.Utils.Generator.BuildTool
From Version 9.0.0-alpha.0.25077.3 -> To Version 9.0.0-alpha.0.25124.3
* Update dependencies from https://github.com/dotnet/hotreload-utils build 20250303.2
Microsoft.DotNet.HotReload.Utils.Generator.BuildTool
From Version 9.0.0-alpha.0.25077.3 -> To Version 9.0.0-alpha.0.25153.2
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
* Update dependencies from https://github.com/dotnet/icu build 20250212.1
Microsoft.NETCore.Runtime.ICU.Transport
From Version 9.0.0-rtm.25105.1 -> To Version 9.0.0-rtm.25112.1
* Update dependencies from https://github.com/dotnet/icu build 20250213.1
Microsoft.NETCore.Runtime.ICU.Transport
From Version 9.0.0-rtm.25105.1 -> To Version 9.0.0-rtm.25113.1
* Update dependencies from https://github.com/dotnet/icu build 20250214.1
Microsoft.NETCore.Runtime.ICU.Transport
From Version 9.0.0-rtm.25105.1 -> To Version 9.0.0-rtm.25114.1
* Update dependencies from https://github.com/dotnet/icu build 20250307.1
Microsoft.NETCore.Runtime.ICU.Transport
From Version 9.0.0-rtm.25105.1 -> To Version 9.0.0-rtm.25157.1
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil
From Version 0.11.5-alpha.25102.5 -> To Version 0.11.5-alpha.25112.2
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Update dependencies from https://github.com/dotnet/emsdk build 20250213.2
Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport
From Version 9.0.3-servicing.25105.2 -> To Version 9.0.3-servicing.25113.2
* Update dependencies from https://github.com/dotnet/emsdk build 20250214.2
Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport
From Version 9.0.3-servicing.25105.2 -> To Version 9.0.3-servicing.25114.2
Dependency coherency updates
runtime.linux-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.win-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.win-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.osx-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.osx-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
From Version 19.1.0-alpha.1.24575.1 -> To Version 19.1.0-alpha.1.25113.2 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport
* Update dependencies from https://github.com/dotnet/emsdk build 20250307.2
Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport
From Version 9.0.3-servicing.25105.2 -> To Version 9.0.4-servicing.25157.2
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Common , Microsoft.DotNet.XHarness.TestRunners.Xunit
From Version 9.0.0-prerelease.25103.3 -> To Version 9.0.0-prerelease.25113.3
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
* Update dependencies from https://github.com/dotnet/roslyn build 20250223.1
Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset
From Version 4.12.0-3.25105.5 -> To Version 4.12.0-3.25123.1
* Update dependencies from https://github.com/dotnet/roslyn build 20250224.2
Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset
From Version 4.12.0-3.25105.5 -> To Version 4.12.0-3.25124.2
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
Microsoft.CodeAnalysis.Analyzers , Microsoft.CodeAnalysis.NetAnalyzers
From Version 3.11.0-beta1.25076.3 -> To Version 3.11.0-beta1.25123.3
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Stop counting work items from ThreadPoolTypedWorkItemQueue for ThreadPool.CompletedWorkItemCount (#106854)
* Stop counting work items from ThreadPoolTypedWorkItemQueue as completed work items
---------
Co-authored-by: Eduardo Manuel Velarde Polar <evelardepola@microsoft.com>
Co-authored-by: Koundinya Veluri <kouvel@users.noreply.github.com>
* Make counting of IO completion work items more precise on Windows
- Follow-up to https://github.com/dotnet/runtime/pull/106854. Issue: https://github.com/dotnet/runtime/issues/104284.
- Before the change, the modified test case often yields 5 or 6 completed work items, due to queue-processing work items that happen to not process any user work items. After the change, it always yields 4.
- Looks like it doesn't hurt to have more-precise counting, and there was a request to backport a fix to .NET 8, where it's more necessary to fix the issue
---------
Co-authored-by: Eduardo Velarde <32459232+eduardo-vp@users.noreply.github.com>
Co-authored-by: Eduardo Manuel Velarde Polar <evelardepola@microsoft.com>
* Do not overwrite gcrefs masks present in reg1/reg2 fields
* Temporary use debian 10
* Revert "Temporary use debian 10"
This reverts commit 269225f46b97d0d511510688504658b695e86822.
---------
Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>
Co-authored-by: Jeff Schwartz <jeffschw@microsoft.com>
A balancing group can result in TransferCapture being emitted with a negative "capnum". If the compiler is running under a culture that uses something other than '-' as the negative sign, the resulting generated code will fail to compile.
- On Windows, checking CPU utilization seems to involve a small amount of overhead, which can become noticeable or even significant in some scenarios. This change makes the intervals of time over which CPU utilization is computed configurable. Increasing the interval increases the period at which CPU utilization is updated. The same config var can also be used to disable CPU utilization checks and have features that use it behave as though CPU utilization is low.
- CPU utilization is used by the starvation heuristic and hill climbing. When CPU utilization is very high, the starvation heuristic reduces the rate of thread injection in starved cases. When CPU utilization is high, hill climbing avoids settling on higher thread count control values.
- CPU utilization is currently updated when the gate thread performs periodic activities, which happens typically every 500 ms when a worker thread is active. There is one gate thread per .NET process.
- In scenarios where there are many .NET processes running, and where many of them frequently but lightly use the thread pool, overall CPU usage may be relatively low, but the overhead from CPU utilization checks can bubble up to a noticeable portion of overall CPU usage. In a scenario involving 100s of .NET processes, it was seen that CPU utilization checks amount to 0.5-1% of overall CPU usage on the machine, which was considered significant.
* JIT: fix local assertion prop error for partial local comparisons
If a JTRUE comparison only involves part of a local value we cannot make assertions
about the local as a whole.
Fixes#111352.
* restrict to TYP_LONG locals
---------
Co-authored-by: Andy Ayers <andya@microsoft.com>
When getting a resource where `ResourceResolve` handler returns an assembly with a manifest resource that is an assembly ref, we incorrectly resolved the reference on the original assembly instead of the assembly returned by the handler and then also looked for the resource on the original assembly again instead of using the referenced assembly.
This change includes a test for this case using IL. The manifest resource file (as opposed to assembly ref) case is already covered in libraries tests.
* Add support for LDAPTLS_CACERTDIR \ TrustedCertificateDirectory (#111877)
* Add CompatibilitySuppressions.xml
* Remove unwanted test changes that were ported from v10
Previously this would only include the PDB for the primary output which
missed any other additions to TfmRuntimeSpecificPackageFile - such as
those from references or packages.
Co-authored-by: Eric StJohn <ericstj@microsoft.com>
The wrapper was relatively recently changed to icall into mono_get_addr_compiled_method in order to obtain a native function pointer to call using calli. This is incorrect on interpreter where we expect an `InterpMethod*`. This commit adds a new opcode instead, that on jit it goes through the same icall path, while on interpeter in similarly computes the appropiate method to call.
On a separate track, it might be useful to investigate whether the necessary delegate invoke wrapper should have been present in the aot image and not be executed with the interpreter in the first place.
Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>
Co-authored-by: Steve Pfister <steveisok@users.noreply.github.com>
method_make_alwaysthrow_typeloadfailure replaces the entire method code with a throw of type load exception. This behaviour not only seem dubious, if it is triggered from inlining a method, that might never even get called, but it also does changes to the set of basic blocks that can lead to crashes later on during compilation.
Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>
When the Take amount is larger than the number of elements in the source `Iterator<T>`, Last ends up throwing an exception and LastOrDefault ends up returning the default value, rather than returning the last value in the taken region.
As part of fixing this, I sured up the tests to try to cover more such sequences of operations. In doing so, the tests got a lot slower, so I tracked down and fixed places where we were doing a lot of unnecessary work.
The IL link file was getting included as unnecessary content in transitive dependent projects which caused confusion.
Fixes#112110
Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>
* Move generation of SuggestedBindingRedirects.targets to inner build
These targets depend on the AssemblyVersion of the library which is
specific to the inner-build of the library. Generate them in the inner-build.
* Update src/libraries/System.Resources.Extensions/src/System.Resources.Extensions.csproj
---------
Co-authored-by: Eric StJohn <ericstj@microsoft.com>
