-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[release/10.0] Revert generic number tricks #120729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
+18,035
−7,656
Conversation
This file contains hidden or 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
Mop-up commits from the end of the merge window for RC1
…net#118829) This lets us keep some of the constant-time indexing advantages of the IList iterator, without the GVM overhead of Select. There is a small size increase here, but nowhere near the cost of the GVM. In a pathological generated example for GVMs the cost was: 1. .NET 9: 12 MB 2. .NET 10 w/out this change: 2.2 MB 3. .NET 10 w/ this change: 2.3 MB In a real-world example (AzureMCP), the size attributed to System.Linq was: 1. .NET 9: 1.2 MB 2. .NET 10 w/out this change: 340 KB 3. .NET 10 w/ this change: 430 KB This seems like a good tradeoff. We mostly keep the algorithmic complexity the same across the size/speed-opt versions, and just tradeoff on the margins. We could probably continue to improve this in the future.
…t/filters from C++/CLI (dotnet#118905) * JIT: fix issue with EH clause class types for fault/filters from C++/CLI C++/CLI appears to leave the CORINFO_EH_CLAUSE ClassToken/FilterOffset union set to some nonzero value for fault/filter clauses. The JIT currently just passes this value along to the runtime. If a method with such a nonzero field is inlined into a dynamic method, this trips up a check in the runtime where a nonzero entry for such a field is interpreted as a class handle, even for fault/filter clauses where it should be ignored. Tolerate this by zeroing the field in the JIT. Note this could not have happened in pre .NET10 as methods with EH could not be inlined, so a dynamic method would never see such an EH clause, and in non-dynamic methods this field is ignored for faults and filters. Fixes dotnet#118837. * review feedback * zero eh table on alloc/realloc --------- Co-authored-by: Andy Ayers <[email protected]>
…t#118854) * Add trim analysis for implicit constructors * Fix RequiresExcludeStatics test * Fix test for native AOT * Fix test, move to base analyzer * Clean up whitespace * Fix RegexLWCGCompiler annotations This was warning on the implicit ctor. --------- Co-authored-by: Sven Boemer <[email protected]>
…ization for managed C++ (dotnet#118964) * IJW workaround * Update src/coreclr/vm/ceemain.cpp Co-authored-by: Copilot <[email protected]> --------- Co-authored-by: Jan Kotas <[email protected]> Co-authored-by: Copilot <[email protected]>
…sions (dotnet#119054) * [Android] Avoid calling membarrier on older Android versions * Initialize s_helperPage on older Androids
…fyHash (dotnet#118950) Co-authored-by: Simon Rozsival <[email protected]>
Free malloc-ed data that is no longer used after method execution. Co-authored-by: Vlad Brezae <[email protected]>
…essage event (dotnet#119085) - fix status for wasm_ws_close_sent Co-authored-by: Pavel Savara <[email protected]>
…zer in a shared library (dotnet#119082) * Fix deadlock when creating threads from ModuleInitializer in a shared library The problem is that the first time we reverse p/invoke into an API in the shared library, we need to do two things: initialize runtime and run module initializers. Running module initializers is done as part of runtime initialization in the shared library case because it was convenient to do it there (in the EXE case, we run them after runtime initialization, right before Main). The problem with running it as part of the runtime initialization is that the arbitrary user code can deadlock us (see the issues for stack). This separates runtime initialization and running module initializers. Doing just that doesn't fix the problem though because the deadlock we saw is part of thread creation. So we'd just deadlock on the module initializer runner. This introduces a new kind of reverse p/invoke enter routine that doesn't wait for module initializers. Instead we wait for module initializers before we are ready to run user code on the thread (and the thread is initialized just enough that ThreadStart can make progress). This also fixes a potential issue in the EXE case where threads created from module initializers could start running before we're finished running module initializers. Instead this introduces a new opportunity for deadlocking :(. I don't actually like this fix. But we need to do something about it because EventSource does exactly this (dotnet#118773). Fixes dotnet#118773. Fixes dotnet#107699. * Revert everything but the test * Cleaner fix if it works * Not this * FB * Update thread.cpp * Update src/coreclr/nativeaot/Runtime/thread.cpp Co-authored-by: Jan Kotas <[email protected]> * Update main.cpp * Update main.cpp * Update ThreadEntryPoint signature for platform compatibility * Update main.cpp --------- Co-authored-by: Michal Strehovský <[email protected]> Co-authored-by: Jan Kotas <[email protected]> Co-authored-by: Jeff Schwartz <[email protected]>
… name/type (dotnet#119080) * Fixup some Vector<T> function lookups to use the right name/type * Update src/tests/JIT/Regression/JitBlue/Runtime_119008/Runtime_119008.cs --------- Co-authored-by: Tanner Gooding <[email protected]>
…net#118908) * Avoid marking types as reflected on in CreateSpan This seems to be at least one of the reasons why Hello World on Linux still needs support for boxed enums. `CreateSpan` is used with an enum type in Unix System.Console, which brings a boxed enum into whole program view and we can't undo the damage this causes to the whole program view during compilation anymore (even though we no longer need the `typeof` then because RyuJIT always expands `CreateSpan`). * Update src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.cs --------- Co-authored-by: Michal Strehovský <[email protected]>
Prevents hard to diagnose crashes caused by COM interop rehydrating wrong type. Co-authored-by: Jan Kotas <[email protected]>
… Arm32 (dotnet#119150) * NativeAOT specific register window implementation has to match the one in libunwind. * Re-enable test * Make the test more robust
…#119168) TS_GCSuspendRedirected is normally cleared in the slow path of pulsing GC mode (RareDisablePreemptiveGC). The problem is that we may not even get to that slow path if the thread gets rescheduled right after we switch to preemptive mode and gets scheduled back only after the GC completes and resumes execution. This change clears it explicitly. Fixes dotnet#119149 Co-authored-by: Jan Kotas <[email protected]>
…otnet#119055) * JIT: Consistently DNER promoted struct parameters on arm32 `lvaGetPromotionType` always returns dependent promotion for this case, but `lvDoNotEnregister` was not consistently set. With this PR we instead consistently just set `lvDoNotEnregister` for these parameters. * Also set it for decomposed longs --------- Co-authored-by: Jakob Botsch Nielsen <[email protected]>
…o-release/10.0 [automated] Merge branch 'release/10.0-rc1' => 'release/10.0'
This fixes unbounded shadow stack growth that leads to stack overflow exception when exceptions are thrown and caught in a loop. Fixes dotnet#118913 Fixes dotnet#107418 Co-authored-by: Jan Kotas <[email protected]>
…otnet#119175) * JIT: Disallow widening tailcalls in async functions The JIT allows tailcalls that depend on widening happening in the callee: e.g. an int32 returning function can tailcall an int16 returning function because the managed ABI specifies that the callee will widen anyway. However, this is not legal for async methods. For async methods the int32 and int16 returning functions come with two different resumption stubs that are responsible for propagating the returned result into the next continuation in asynchronous cases. Allowing an int32 -> int16 tailcall means only a 16-bit value gets propagated into a caller that expects 32 bits to be written into its continuation. Fix dotnet#119060 * Rename * Fix test class name * Comment out some asserts for now --------- Co-authored-by: Jakob Botsch Nielsen <[email protected]>
…io in Mono. (dotnet#118878) * Implement UnhandledException hook for finalizers in Mono. * Cache the finalize method on wasm * Precompile invoke helper for GuardedFinalize * only check for GuardedFinalize in corlib * make GuardedFinalize virtual * use mono_runtime_try_invoke, since we can wih instance methods * comment out unused * Move GuardedFinalize to a helper class * make it static * some cleanup * remove no longer relevant comment * Disable UnhandledExceptionHandler tests with foreign threads on `llvmfullaot` (dotnet#119039) These kind of tests are not compatible. --------- Co-authored-by: vsadov <[email protected]> Co-authored-by: Vladimir Sadov <[email protected]>
…net#119044) * Throttle finalization a bit when doing GC stress. * fix indentation --------- Co-authored-by: vsadov <[email protected]>
[[ commit created by automation ]]
Updated Dependencies: Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.Analyzers, Microsoft.CodeAnalysis.CSharp, Microsoft.Net.Compilers.Toolset (Version 5.0.0-2.25414.103 -> 5.0.0-2.25427.104) Microsoft.CodeAnalysis.NetAnalyzers (Version 10.0.0-preview.25414.103 -> 10.0.100-rc.1.25427.104) Microsoft.DotNet.ApiCompat.Task, Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport (Version 10.0.100-rc.1.25414.103 -> 10.0.100-rc.1.25427.104) Microsoft.DotNet.Arcade.Sdk, Microsoft.DotNet.Build.Tasks.Archives, Microsoft.DotNet.Build.Tasks.Feed, Microsoft.DotNet.Build.Tasks.Installers, Microsoft.DotNet.Build.Tasks.Packaging, Microsoft.DotNet.Build.Tasks.TargetFramework, Microsoft.DotNet.Build.Tasks.Templating, Microsoft.DotNet.Build.Tasks.Workloads, Microsoft.DotNet.CodeAnalysis, Microsoft.DotNet.GenAPI, Microsoft.DotNet.GenFacades, Microsoft.DotNet.Helix.Sdk, Microsoft.DotNet.PackageTesting, Microsoft.DotNet.RemoteExecutor, Microsoft.DotNet.SharedFramework.Sdk, Microsoft.DotNet.XliffTasks, Microsoft.DotNet.XUnitExtensions (Version 10.0.0-beta.25414.103 -> 10.0.0-beta.25427.104) Microsoft.DotNet.Cecil (Version 0.11.5-alpha.25414.103 -> 0.11.5-alpha.25427.104) Microsoft.DotNet.XUnitAssert, Microsoft.DotNet.XUnitConsoleRunner (Version 2.9.3-beta.25414.103 -> 2.9.3-beta.25427.104) Microsoft.NET.Sdk.IL, Microsoft.NETCore.App.Ref, Microsoft.NETCore.ILAsm, runtime.native.System.IO.Ports, System.Reflection.Metadata, System.Reflection.MetadataLoadContext, System.Text.Json (Version 10.0.0-rc.1.25414.103 -> 10.0.0-rc.2.25427.104) NuGet.Frameworks, NuGet.Packaging, NuGet.ProjectModel, NuGet.Versioning (Version 7.0.0-preview.1.42003 -> 7.0.0-preview.1.42804) System.CommandLine (Version 2.0.0-rc.1.25414.103 -> 2.0.0-rc.2.25427.104)
(cherry picked from commit d2f5000)
(cherry picked from commit 503100d)
(cherry picked from commit db0d37a)
* Fix elfreader for android. * Update src/coreclr/debug/dbgutil/elfreader.cpp Co-authored-by: Jan Kotas <[email protected]> * Update src/coreclr/debug/dbgutil/elfreader.cpp Co-authored-by: Jan Kotas <[email protected]> --------- Co-authored-by: Thays Grazia <[email protected]> Co-authored-by: Jan Kotas <[email protected]>
…#119195) * Add trim analyzer support for C# 14 extensions (dotnet#119017) Fixes dotnet#115949 This adds Roslyn analyzer support for C# 14 extensions. A few notes on the behavior: - DAM is supported on method return/params, including on property accessor return/param. - DAM is not supported on extension properties (see dotnet#119113) - DAM is not supported on extension methods (this produces IL2041) - There's still a bug with the behavior for ILLink/ILC due to the annotations not being preserved into the implementation when lowering: dotnet/roslyn#80017. Includes an update to Microsoft.CodeAnalysis for new analyzer APIs involving extension members. dotnet#119159 tracks fixing new warnings that are suppressed for now. New tests uncovered an analyzer issue with operators in the (extension or not): dotnet#119110. This change includes test coverage for non-extension operators. They also uncovered an issue that looks like a race condition in ILC: dotnet#119155. * Fix indentation
…otnet#120264) Co-authored-by: Jeff Handley <[email protected]>
…ild 20250929.2 (dotnet#120299) On relative base path root Microsoft.DotNet.HotReload.Utils.Generator.BuildTool From Version 10.0.0-alpha.0.25465.1 -> To Version 10.0.0-alpha.0.25479.2 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Backflow from https://github.com/dotnet/dotnet / e72b5bb build 285185 [[ commit created by automation ]] * Update dependencies from https://github.com/dotnet/dotnet build 285185 Updated Dependencies: Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.Analyzers, Microsoft.CodeAnalysis.CSharp, Microsoft.Net.Compilers.Toolset (Version 5.0.0-2.25473.111 -> 5.0.0-2.25479.115) Microsoft.CodeAnalysis.NetAnalyzers, Microsoft.DotNet.ApiCompat.Task, Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport (Version 10.0.100-rc.2.25473.111 -> 10.0.100-rtm.25479.115) Microsoft.DotNet.Arcade.Sdk, Microsoft.DotNet.Build.Tasks.Archives, Microsoft.DotNet.Build.Tasks.Feed, Microsoft.DotNet.Build.Tasks.Installers, Microsoft.DotNet.Build.Tasks.Packaging, Microsoft.DotNet.Build.Tasks.TargetFramework, Microsoft.DotNet.Build.Tasks.Templating, Microsoft.DotNet.Build.Tasks.Workloads, Microsoft.DotNet.CodeAnalysis, Microsoft.DotNet.GenAPI, Microsoft.DotNet.GenFacades, Microsoft.DotNet.Helix.Sdk, Microsoft.DotNet.PackageTesting, Microsoft.DotNet.RemoteExecutor, Microsoft.DotNet.SharedFramework.Sdk, Microsoft.DotNet.XliffTasks, Microsoft.DotNet.XUnitExtensions (Version 10.0.0-beta.25473.111 -> 10.0.0-beta.25479.115) Microsoft.DotNet.Cecil (Version 0.11.5-alpha.25473.111 -> 0.11.5-alpha.25479.115) Microsoft.DotNet.XUnitAssert, Microsoft.DotNet.XUnitConsoleRunner (Version 2.9.3-beta.25473.111 -> 2.9.3-beta.25479.115) Microsoft.NET.Sdk.IL, Microsoft.NETCore.App.Ref, Microsoft.NETCore.ILAsm, runtime.native.System.IO.Ports, System.Reflection.Metadata, System.Reflection.MetadataLoadContext, System.Text.Json (Version 10.0.0-rc.2.25473.111 -> 10.0.0-rtm.25479.115) NuGet.Frameworks, NuGet.Packaging, NuGet.ProjectModel, NuGet.Versioning (Version 7.0.0-preview.2.47411 -> 7.0.0-rc.48015) System.CommandLine (Version 2.0.0-rc.2.25473.111 -> 2.0.0-rtm.25479.115) --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…0148) Co-authored-by: Max Charlamb <[email protected]>
test only change.
… it is an empty one. (dotnet#120334) * If we receive an empty update we should just ignore it. * Update src/mono/mono/component/hot_reload.c Co-authored-by: Copilot <[email protected]> --------- Co-authored-by: Thays Grazia <[email protected]> Co-authored-by: Thays Grazia <[email protected]> Co-authored-by: Copilot <[email protected]>
* Bump OSX.12 helix queues to OSX.13 * More bumps --------- Co-authored-by: Steve Pfister <[email protected]>
…et#120372) This reverts commit a074813. Co-authored-by: Aaron Robinson <[email protected]>
* Fix CopyOSContext on amd64 The CopyOSContext was skipping floating point registers on amd64. There was an obsolete comment that on some older Windows, the vector registers are not present in the context. I've found to be a problem when porting nativeAOT EH to CoreCLR and to make the context flags correct, I've removed the CONTEXT_FLOATING_POINT from the ContextFlags. But it now turned out that it prevents EH from correctly restoring non-volatile floating point registers after a catch. Since he ContextFlags don't contain the CONTEXT_FLOATING_POINT, the floating point registers were not restored during the resume. This change fixes it by removing the amd64 specific handling and always copying the whole CONTEXT structure. It just masks off the CONTEXT_XSTATE, as the XSTATE is stored out of the basic CONTEXT. Close dotnet#118564 * Fix build break - CONTEXT_XSTATE exists on some targets only --------- Co-authored-by: Jan Vorlicek <[email protected]>
) * [release/10.0] Move coreclr EH second pass to native code There were some GC holes discovered caused by the fact that GC can be triggered during 2nd pass of EH in-between calls to finally handlers and catch handler. After considering options, moving the 2nd pass to native code seems the most reasonable solution. * Disable interpreter test for .NET 10 * Fix casing of path in the interpreter test disabling
* Add proper locking in TranslateSigHelper * Try to please the compiler * Update src/coreclr/md/enc/mdinternalrw.cpp --------- Co-authored-by: Kevin Gosse <[email protected]> Co-authored-by: Jan Kotas <[email protected]>
* JIT: Fix heap allocations Also override the global new operators to assert unconditionally, to catch this common pitfall proactively. * Nit * Fix x86 build * Nit * Address feedback * Update src/coreclr/jit/CMakeLists.txt Co-authored-by: Copilot <[email protected]> * Remove diagnostic from 10.0 backport --------- Co-authored-by: Jakob Botsch Nielsen <[email protected]> Co-authored-by: Copilot <[email protected]>
* Localized file check-in by OneLocBuild Task: Build definition ID 679: Build ID 2797048 (dotnet#119880) * Localized file check-in by OneLocBuild Task: Build definition ID 679: Build ID 2801850 (dotnet#119910) --------- Co-authored-by: dotnet bot <[email protected]>
… target (dotnet#120387) * Limit the use of a pointer to the lexical scope of the target * Update src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/StorePal.Windows.Export.cs Co-authored-by: Jan Kotas <[email protected]> --------- Co-authored-by: Jeremy Barton <[email protected]> Co-authored-by: Jan Kotas <[email protected]>
…otnet-optimization build 20251002.1 (dotnet#120426) On relative base path root optimization.linux-arm64.MIBC.Runtime , optimization.linux-x64.MIBC.Runtime , optimization.windows_nt-arm64.MIBC.Runtime , optimization.windows_nt-x64.MIBC.Runtime , optimization.windows_nt-x86.MIBC.Runtime , optimization.PGO.CoreCLR From Version 1.0.0-prerelease.25467.1 -> To Version 1.0.0-prerelease.25502.1 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
….1 (dotnet#120350) On relative base path root Microsoft.NETCore.Runtime.ICU.Transport From Version 10.0.0-rc.2.25466.2 -> To Version 10.0.0-rtm.25502.1 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Long symbol names were truncated, leading to duplicate names in the generated assembly file. This was making the compiler fail due to duplicate symbol names. Co-authored-by: Vlad Brezae <[email protected]>
…) (dotnet#120567) Co-authored-by: Pranav Senthilnathan <[email protected]>
…om build (dotnet#120548) * Expect fingerprint in assemblies promoted from build * Expect fingerprint in assemblies promoted from build * Fix satellite assemblies * Feedback --------- Co-authored-by: Marek Fišera <[email protected]>
The bitcast transformation produces `BITCAST(LCL_VAR)`, but for SIMDs the local can be promoted and this ends up resulting in invalid IR. We would normally go through the `LCL_FLD` path that DNERs the local, so make sure we still do that. Co-authored-by: Jakob Botsch Nielsen <[email protected]>
…at results in incorrectly triggered ICorProfiler callbacks (dotnet#120515) * Fix race on assembly initialize - delay assembly creation until after FileLoadLock creation * Update moduleload profiler test * Apply suggestions from code review Co-authored-by: Aaron Robinson <[email protected]> * PR feedback - asserts --------- Co-authored-by: Elinor Fung <[email protected]> Co-authored-by: Aaron Robinson <[email protected]>
…otnet#120569) * Avoid referencing types of JsonIgnore'd properties. * Apply suggestion from @Copilot Co-authored-by: Copilot <[email protected]> * Revert use of Range and Index for down-level support This reverts commit ed3bcc3. * Address feedback. --------- Co-authored-by: Eirik Tsarpalis <[email protected]> Co-authored-by: Copilot <[email protected]> Co-authored-by: Jeff Handley <[email protected]>
…t#120371) * Fix issue with array interface devirtualization The instantiated methods should use the parameter type of the interface, not the element type of the array. Fixes dotnet#120270. * review feedback * add test that fails for ref type arrays * revise tests to not hard code the name of the enumerator type --------- Co-authored-by: Andy Ayers <[email protected]>
…ering (dotnet#120572) * Add MetadataUpdateDeletedAttribute (dotnet#119584) This attribute is intended to be emitted only by Roslyn. Its intent is to be used by reflection as a filter to "remove" types and members that have been deleted during a hot reload session. Implements dotnet#118903 * Add ability to filter members in reflection and test --------- Co-authored-by: Tomas Matousek <[email protected]> * Fix assert message with errant text pasted in (dotnet#120574) --------- Co-authored-by: Steve Pfister <[email protected]> Co-authored-by: Tomas Matousek <[email protected]>
There is a problem with RtlRestoreContext not restoring context during ThreadAbort if that abort comes from injected APC callback on ARM64 and the processor supports SVE. In that case, the context provided by the APC callback can contain XSTATE and when we start walking stack from that context, we copy that context into the REGDISPLAY. The problem is that we copy the ContextFlags without changes, so if they contained CONTEXT_XSTATE flag, it is kept set even though the REGDISPLAY has only plain old CONTEXT without any xstate. When we call RtlRestoreContext in the ResumeAfterCatch, it fails because the XSTATE is not valid and so it returns. That's unexpected and we end up crashing with an assert. The fix clears the CONTEXT_XSTATE in ResumableFrame::UpdateRegDisplay so that the REGDISPLAY ContextFlags are validly representing the context. Close dotnet#120437 Co-authored-by: Jan Vorlicek <[email protected]>
Co-authored-by: Jan Kotas <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
linkable-framework
Issues associated with delivering a linker friendly framework
needs-area-label
An area label is needed to ensure this gets routed to the appropriate area owners
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.
No description provided.