[pull] main from dotnet:main #3
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…t` instead (#112161) * Change workflows to use pull_request_target instead of pull_request event * Add CODEOWNERS entry * Add initial readme
* Fix handling H3_NO_ERROR * Revert using change
…#112147) Cast expansion can expand into a `BBJ_THROW` block. If that happens and that block has flow into it, the PGO data becomes inconsistent.
…04.1 (#112174) Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport , Microsoft.SourceBuild.Intermediate.emsdk From Version 10.0.0-preview.2.25103.1 -> To Version 10.0.0-preview.2.25104.1 Dependency coherency updates runtime.linux-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.linux-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.osx-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.osx-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.win-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.win-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport From Version 10.0.0-alpha.1.25077.1 -> To Version 10.0.0-alpha.1.25103.1 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…204.11 (#112175) Microsoft.SourceBuild.Intermediate.roslyn , Microsoft.CodeAnalysis , Microsoft.CodeAnalysis.CSharp , Microsoft.Net.Compilers.Toolset From Version 4.14.0-2.25081.4 -> To Version 4.14.0-2.25104.11 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…or Android sample (#111742) By decoupling the initialization of runtime and execution of entry point, we can run the runtime initialization synchronously, forcing the onCreate callback to report the Displayed <name> for user 0: <time> after the runtime is fully initialized. The execution of the entry point is still performed asynchronously to prevent the freeze of main thread for strenuous executables. --------- Co-authored-by: Ivan Povazan <[email protected]>
…112025) - Consolidate the 2 functions so we only need 1 copy of the C++ code (JIT_Patchpoint and JIT_PartialCompilationPatchpoint are still separate entrypoints, but the real meat of the logic is now all in PatchpointWorkerWorkerWithPolicy) - Instead of using a managed function, I decided to use a transition frame to manage the case of calling into the runtime. In this case we are able to re-use the DynamicHelperFrame which appears to be sufficient. - Add asm helpers in the current architectures which support on stack replacement to setup the TransitionBlock and call into the common C++ code --------- Co-authored-by: Jan Kotas <[email protected]> Co-authored-by: Andy Ayers <[email protected]>
Reduce the amount of graph walking needed somewhat. Use compile time handles consistently.
…ackage (#111876) * Allow the NativeAOT runtime pack to be specified as the ILC runtime package * Put the property in a PropertyGroup * Finish sentence * PR feedback
* make sure the memorystream is disposed * more cleanup * Just write to the filestream directly * Remove explicit flushes * just write bytes
* Factor positive lookaheads better into find optimizations A positive lookahead at the start of a pattern can be used for determining find optimizations even when the non-zero-width portions of the pattern aren't. This helps particularly in cases where the positive lookahead contains an anchor or a literal. Also extends the existing alternation reduction optimization to factor out anchors that begin every branch of an alternation.
Revival of #112105. Add a switch to FlowGraphDfsTree that indicates if its traversal used edge likelihoods to determine the order in which successors were visited. This switch can then be used by debug checks that verify the DFS's correctness to check both types of trees. This functionality means we can frequently reuse the DFS tree annotations computed by LSRA throughout block layout.
We need to override this in UnityLinker
…107945) When a nested exported type is marked via link.xml and the declaring type is not marked, cecil will write out an invalid exported type table which will lead to exceptions such as ``` System.ArgumentOutOfRangeException : Specified argument was out of the range of valid values. at Mono.Collections.Generic.Collection`1.get_Item(Int32 index) at Mono.Cecil.MetadataReader.ReadExportedTypes() at Mono.Cecil.ModuleDefinition.<>c.<get_ExportedTypes>b__116_0(ModuleDefinition _, MetadataReader reader) at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TRet& variable, TItem item, Func`3 read) at Mono.Cecil.ModuleDefinition.get_ExportedTypes() at Mono.Cecil.MetadataResolver.GetType(ModuleDefinition module, TypeReference reference) at Mono.Cecil.MetadataResolver.Resolve(TypeReference type) at Mono.Linker.Tests.TestCasesRunner.TestResolver.TryResolve(TypeReference typeReference) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\test\Trimming.Tests.Shared\TestResolver.cs:line 12 at Mono.Linker.ModuleDefinitionExtensions.ResolveType(ModuleDefinition module, String typeFullName, ITryResolveMetadata resolver) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\src\linker\Linker\ModuleDefinitionExtensions.cs:line 50 at Mono.Linker.TypeNameResolver.<ResolveTypeName>g__GetSimpleTypeFromModule|6_0(TypeName typeName, ModuleDefinition module) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\src\linker\Linker\TypeNameResolver.cs:line 135 at Mono.Linker.TypeNameResolver.ResolveTypeName(AssemblyDefinition originalAssembly, TypeName typeName, List`1 typeResolutionRecords) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\src\linker\Linker\TypeNameResolver.cs:line 101 at Mono.Linker.TypeNameResolver.TryResolveTypeName(AssemblyDefinition assembly, String typeNameString, TypeReference& typeReference, List`1& typeResolutionRecords) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\src\linker\Linker\TypeNameResolver.cs:line 44 at Mono.Linker.Tests.TestCasesRunner.ResultChecker.VerifyLinkingOfOtherAssemblies(AssemblyDefinition original) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\test\Mono.Linker.Tests\TestCasesRunner\ResultChecker.cs:line 320 at Mono.Linker.Tests.TestCasesRunner.ResultChecker.Check(TrimmedTestCaseResult linkResult) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\test\Mono.Linker.Tests\TestCasesRunner\ResultChecker.cs:line 114 at Mono.Linker.Tests.TestCases.All.Run(TestCase testCase) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\test\Mono.Linker.Tests\TestCases\TestSuites.cs:line 305 at Mono.Linker.Tests.TestCases.All.TypeForwardingTests(TestCase testCase) in E:\UnitySrc\dev\unity-runtime-1\src\tools\illink\test\Mono.Linker.Tests\TestCases\TestSuites.cs:line 262 at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor) at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr) ``` Or if you were to try and open the linked `Forwarder.dll` without the fix in something like ILSpy, it would crash ILSpy. An easy way to fix this seems to be marking the declaring type.
* Condition labeling workflows to only run on dotnet/runtime. * Improve readme * Add jeffhandley as explicit workflow owner Co-authored-by: Jeff Handley <[email protected]>
…12170) Add more detailed explanations to control-flow RegexOpcode values
…ze more Microsoft.Interop.SourceGeneration shared code (#107769)
Contributes to #108553 Tested using `!sos ip2md <ip>`. --------- Co-authored-by: Max Charlamb <[email protected]> Co-authored-by: Elinor Fung <[email protected]>
Adds a feature flag to allow Linq Select to not use a GVM implementation.
This fixes the Loader\classloader\InterfaceFolding\Ambiguous test.
For the following program in pseudo-C# (test is in IL since this is not valid C#):
```csharp
B<int, int> b = new B<int, int>();
if (!(((I<int>)b).Foo() != "B::Foo2"))
{
B<string, string> b2 = new B<string, string>();
if (!(((I<string>)b2).Foo() != "B::Foo2"))
{
Console.WriteLine("Pass");
return 100;
}
}
Console.WriteLine("Failed!");
return -1;
interface I<T>
{
string Foo();
}
class A<U> : I<U>
{
string I<U>.Foo() => "A::Foo";
}
internal class B<V, W> : A<V>, I<W>
{
string I<W>.Foo() => "B::Foo1";
string I<V>.Foo() => "B::Foo2";
}
```
We incorrectly resolve the interface call into `B::Foo1` because `I<int>.Foo` could be implemented by both `Foo1` and `Foo2` methods and we just pick whatever we see first. Per ECMA-335: "If there are multiple methods for the same interface method (i.e. with different generic type parameters), place them in the list in type declaration order of the associated interfaces."
This implements the tie break.
* add important remarks to NrbfDecoder * add a warning about TypeName
Co-authored-by: Jakob Botsch Nielsen <[email protected]>
* Specialize Contains for Iterators in LINQ It appears that Contains ends up being reasonably common after a series of LINQ operations, whether explicitly at the call site or because a method that returns an enumerable uses LINQ internally and then the call site does Contains. We can optimize Contains for a bunch of operators, just as we can for First/Last. In some cases, we can skip the operator completely, e.g. Contains on a Shuffle or OrderBy is no different from one on the underlying source, in other cases we can optimize by processing the source directly, e.g. a Contains on a Concat can end up doing a Contains on each source, which can in turn pick up vectorized implementations if those individual sources support them. Some of the operators actually already provided Contains implementations as part of implementing IList, and this just makes those implementations accessible. In other cases, new overrides of a new virtual Contains on Iterator are added.
* Remove unnecessary recursion * Feedback - refetch the last error * Fix
* M.E.C.M. Add TryGetValue(ReadOnlySpan<char>) API fix #110504
…e perfBDN app dotnet-install.sh version retrieval. (#112720)
#112256 added the ability to cross compile android on windows. This regressed the win-arm64 crossdac build because it stopped passing CMAKE_TARGET_ARCH and CMAKE_TARGET_OS for cross component builds where the host and target os's match. This change makes sure the cmake variables are passed in all cases.
* Update our signing logic to sign the azl.3 prereqs package with the correct cert * Delete the CBL-Mariner prereqs packages now that we aren't publishing the special Mariner package copies * Remove runtime-deps packages for distros Microsoft doesn't publish packages for any more. These distros publish .NET RPMs themselves. * Remove unused zlib1g dependency from the deb/ubuntu package * Remove old Debian support (pre-Bookworm) and all Ubuntu support from the deb package. We don't publish packages for Ubuntu any more * Update our opensuse/sles packages for Leap 15.6 * Build Deb packages for ARM64 * Update installers.proj * Restore logic for supporting multiple libicu versions, but only include the version that we know any debian distro has.
* Bump the minimum ICU version to 60 As ICU approaches version 80, we need to consider what to do about our ICU version ranges. Our system currently supports a min version of 50 and a max of "min + 30", so 80. ICU60 is the version that shipped with Ubuntu 18.04, which is the distro that we base our libc version on. For Alpine, the version of ICU in the distro we base our libc on (3.17) ships with ICU 72. I recommend that we bump our min to ICU60, which will by our current rules bump our max to ICU90, which will give us more runway. I'd recommend holding off on merging this until #112671 is merged, as that PR changes our deps packages to better describe scenarios where we actually ship packages today. * Remove old optional definition
* Fix exception handling in the prestub worker There is a bug in the new exception handling when ThePreStub is called from CallDescrWorkerInternal and the exception is propagated through that. One of such cases is when a managed class is being initialized during JITting and the constructor is in an assembly that's not found. The bug results in skipping all the native frames upto a managed frame that called that native chain that lead to the exception. In the specific case I've mentioned, a lock in the native code is left in locked state. That later leads to a hang. This was case was observed with Roslyn invoking an analyzer where one of the dependencies was missing. The fix is to ensure that when ThePreStub is called by CallDescrWorkerInternal, the exception is not caught in the PreStubWorker. It is left flowing into the native calling code instead. The same treatment is applied to ExternalMethodFixupWorker and VSD_ResolveWorker too. On Windows, we also need to prevent the ProcessCLRException invocation to call into the managed exception handling code. * Fix missing ContextFlags setting I was hitting intermittent crashes in the unhandled exception test with GC stress C enabled due to this when GetSSP tried to access the SSP in the extended part of the context. * Fix couple of issues * The previous set of changes removed popping of ExInfos too. That's not correct though. But it should be done in a different place than the ProcessCLRExceptionNew. * There was a problem (even before the fix) that an exception caught in DispatchInfo::InvokeMember was reported (via console log and to the debugger) as unhandled. This change also adds a new flavor of the unhandled exception test that throws an unhandled exception on a secondary thread to exercise the related code path. --------- Co-authored-by: Jan Kotas <[email protected]>
…ude Android logging APIs (#112677) - Define `HOST_ANDROID` for coreclr builds and link to Android logging APIs - Make `jitprintf` use [Android logging APIs](https://developer.android.com/ndk/reference/group/logging) if printing to stdout - This allows us to get [JIT disassembly output](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/jit/viewing-jit-dumps.md#disassembly-output) via logcat
* Clarify comments for `ClrRestoreNonvolatileContextWorker`. --------- Co-authored-by: Jan Kotas <[email protected]>
…ins. (#112737) * Fix stack overflow condition when appending modifiers to resolver chains. * Reinstate accidentally deleted test.
… for Windows (#112724) * Print process and parent process using wmic * Do it for windows only
…112745) Co-authored-by: Stephen Toub <[email protected]>
… dotnet/icu, dotnet/runtime-assets (#112624) * Update dependencies from https://github.com/dotnet/hotreload-utils build 20250210.1 Microsoft.DotNet.HotReload.Utils.Generator.BuildTool From Version 10.0.0-alpha.0.25103.1 -> To Version 10.0.0-alpha.0.25110.1 * Update dependencies from https://github.com/dotnet/cecil build 20250209.3 Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil From Version 0.11.5-alpha.25078.1 -> To Version 0.11.5-alpha.25109.3 * Update dependencies from https://github.com/dotnet/icu build 20250216.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 10.0.0-preview.2.25109.1 -> To Version 10.0.0-preview.2.25116.1 * Update dependencies from https://github.com/dotnet/runtime-assets build 20250217.1 Microsoft.DotNet.CilStrip.Sources , Microsoft.NET.HostModel.TestData , System.ComponentModel.TypeConverter.TestData , System.Data.Common.TestData , System.Drawing.Common.TestData , System.Formats.Tar.TestData , System.IO.Compression.TestData , System.IO.Packaging.TestData , System.Net.TestData , System.Private.Runtime.UnicodeData , System.Runtime.Numerics.TestData , System.Runtime.TimeZoneData , System.Security.Cryptography.X509Certificates.TestData , System.Text.RegularExpressions.TestData , System.Windows.Extensions.TestData From Version 10.0.0-beta.25110.1 -> To Version 10.0.0-beta.25117.1 * Update dependencies from https://github.com/dotnet/icu build 20250219.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 10.0.0-preview.2.25109.1 -> To Version 10.0.0-preview.3.25119.1 * Update dependencies from https://github.com/dotnet/runtime-assets build 20250220.1 Microsoft.DotNet.CilStrip.Sources , Microsoft.NET.HostModel.TestData , System.ComponentModel.TypeConverter.TestData , System.Data.Common.TestData , System.Drawing.Common.TestData , System.Formats.Tar.TestData , System.IO.Compression.TestData , System.IO.Packaging.TestData , System.Net.TestData , System.Private.Runtime.UnicodeData , System.Runtime.Numerics.TestData , System.Runtime.TimeZoneData , System.Security.Cryptography.X509Certificates.TestData , System.Text.RegularExpressions.TestData , System.Windows.Extensions.TestData From Version 10.0.0-beta.25110.1 -> To Version 10.0.0-beta.25120.1 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Update dependencies from https://github.com/dotnet/emsdk build 20250218.1 Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport , Microsoft.SourceBuild.Intermediate.emsdk From Version 10.0.0-preview.2.25117.1 -> To Version 10.0.0-preview.2.25118.1 * Update dependencies from https://github.com/dotnet/emsdk build 20250219.2 Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport , Microsoft.SourceBuild.Intermediate.emsdk From Version 10.0.0-preview.2.25117.1 -> To Version 10.0.0-preview.3.25119.2 Dependency coherency updates runtime.linux-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.linux-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.osx-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.osx-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.win-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport,runtime.win-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport From Version 10.0.0-alpha.1.25110.1 -> To Version 10.0.0-alpha.1.25116.1 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Larry Ewing <[email protected]>
Part of #107749. Introduce a repair phase that runs profile synthesis if the profile was marked inconsistent at some point, and call it at the end of the JIT frontend. LSRA and block layout are likely to benefit from profile consistency, and this is late enough in the JIT that the sources of diffs should be relatively obvious.
Have physical promotion read replacements that map to parameter registers back eagerly in the entry basic block. Reading these back initially makes it more likely that the backend will be able to substitute directly for registers.
* Interpreter wire up
This commit adds a new library for the interpreter. This library is meant to be used as an alt jit compiler, exporting the `getJit` method that returns an interface for method compilation. This library also exports the `getInterpreter` method that returns a separate interface to be used for obtaining any other data from the interpreter library. Method compilation has the following responsability:
- create an InterpMethod* for the MethodDesc that it flags as compiled. On mono, InterpMethod serves as reference to the method to be called (which is embedded throughout the code) and later on, following compilation, it is filled with additional information relevant for execution, mainly the code pointer and size of the frame. On CoreCLR, this structure will likely lose some of its relevance, we will end up referencing MethodDesc's directly in interpreter instructions. In the future, it will probably make more sense to have a few common fields of the InterpMethod (like the frame size) stored as a code header to the interpreter IR, with a InterpMethod pointer to be stored as well in the code header for less frequent data.
- set the CORINFO_FLG_INTERPRETER flag in the MethodDesc. This sets up the method to be called through the InterpreterStub.
- some dummy data that is necessary by the runtime is being generated, mainly the code
The interpreter execution is included in the main coreclr library for convenience and speed. It will be contained in interpexec.h and interpexec.cpp while also including the interpretershared.h header from the interpreter library. This header will contain any defines and types that are relevant both during compilation as well as execution (for example the InterpMethod data or the opcode values). For the execution, InterpFrame is a structure on the native stack that is created for each interpreter frame. It will reference the method being executed as well as pointers to the interpreter stack. InterpThreadContext is a thread local structure that contains execution relevant information for the interpreter, for now it just maintains the position of the interpreter stack pointer.
* Add support for compilation and execution of a simple method
This commit ports over some of the compilation machinery from mono. Method compilation takes place in GenerateCode. It allocates a basic block, goes over the IL code and emits code as it goes, while updating the IL stack state. Method code is kept as a linked list of basic blocks. Each basic block keeps a linked list of instructions. The instruction information is represented by an opcode, source and destination vars and additional instruction data. Once the IL code is imported, the var offset allocator needs to kick in in order to allocate an offset for each variable referenced in the code. Once offsets are allocated the final interpreter IR can be generated, writing the opcode and instruction data linearly in the code, while replacing variable indexes with the actual variable offset.
Unlike the mono interpreter, that maintains the code as an uint16_t stream, we chose to use from the start an int32_t based stream. The mono interpreter runs into limitations when executing very large methods, where some offsets don't fit in the uint16_t space. There will be a performance penalty for this that will be addressed in the distant future, by adding short versions for common opcodes.
* Add interpreter test
The test contains one application that contains a method named `RunInterpreterTests` serving as the interpreter entry point. This application is built only, as it is not the test itself. This application is executed with corerun by the actual test, which waits for the corerun exit code to determine success.
* Stop using a mapping table between MethodDesc and InterpMethod
InterpMethod* is used to handle interpreted method execution on mono, but it is not really needed. For CoreCLR we will turn this structure in a header to the compiled IR code, and identify other methods directly by the IR code pointer. The first pointer slot in the IR code will contain a pointer to the InterpMethod containing any other relevant information needed in the method execution.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )