Add net framework47 to async enumerable #121828
Closed
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 <andya@microsoft.com>
…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 <sbomer@gmail.com>
…ization for managed C++ (dotnet#118964) * IJW workaround * Update src/coreclr/vm/ceemain.cpp Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…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 <simon@rozsival.com>
Free malloc-ed data that is no longer used after method execution. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>
…essage event (dotnet#119085) - fix status for wasm_ws_close_sent Co-authored-by: Pavel Savara <pavelsavara@microsoft.com>
…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 <jkotas@microsoft.com> * Update main.cpp * Update main.cpp * Update ThreadEntryPoint signature for platform compatibility * Update main.cpp --------- Co-authored-by: Michal Strehovský <MichalStrehovsky@users.noreply.github.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com> Co-authored-by: Jeff Schwartz <jeffschw@microsoft.com>
… 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 <tagoo@outlook.com>
…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ý <MichalStrehovsky@users.noreply.github.com>
Prevents hard to diagnose crashes caused by COM interop rehydrating wrong type. Co-authored-by: Jan Kotas <jkotas@microsoft.com>
… 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 <jkotas@microsoft.com>
…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 <jakob.botsch.nielsen@gmail.com>
…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 <jkotas@microsoft.com>
…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 <jakob.botsch.nielsen@gmail.com>
…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 <8218165+VSadov@users.noreply.github.com> Co-authored-by: Vladimir Sadov <vsadov@microsoft.com>
…net#119044) * Throttle finalization a bit when doing GC stress. * fix indentation --------- Co-authored-by: vsadov <8218165+VSadov@users.noreply.github.com>
[[ 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 <jkotas@microsoft.com> * Update src/coreclr/debug/dbgutil/elfreader.cpp Co-authored-by: Jan Kotas <jkotas@microsoft.com> --------- Co-authored-by: Thays Grazia <thaystg@gmail.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com>
…#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
## Customer Impact - [x] Customer reported - [ ] Found internally These issues were reported in dotnet#119706 as problems with clang-21 on Fedora 43. The investigation uncovered that clang introduced a potentially breaking change in clang-20 that we do not currently consume. These build changes impact VMR related builds when linux distrobutions performing source build adopt clang-21. clang-20 breaking change log - https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes. This PR contains the minimal changes needed to fix issues from the following PRs dotnet#120644 and dotnet#120775. ## Regression - [x] Yes - [ ] No Moving to the new clang-21 compiler will cause the runtime to crash. This is a regression from using .NET 10 and the default compiler of clang-19. ## Testing This has been validated using various legs and examples to demonstrate the usage of undefined behavior these flags convert into "defined" behavior in C/C++. ## Risk Low. This makes clang-21 more permissive and is limited to non official product builds. --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com>
dotnet#120961) (dotnet#121555) Backport of dotnet#120601 and dotnet#120961 to release/10.0 # Description Backports Draft 12 and Draft 13 spec changes for Composite ML-DSA. This PR combines two related updates: **Draft 12 changes (dotnet#120601):** - Mandate parameters field in ECPrivateKey (previously omitted) - `CompositeMLDsaAlgorithm.cs`: Calculate parameters field size for EC curves (P256/P384/P521/brainpool variants) - `CompositeMLDsaManaged.ECDsa.cs`: Validate parameters presence and curve match; write parameters with context-specific tag [0] - `CompositeMLDsaManaged.cs`: Update spec references from draft-08 to draft-12 - Test updates: Add validation for wrong/missing/implicit/explicit curves; update expected key sizes per spec Table 4 **Draft 13 changes (dotnet#120961):** - Update OIDs from experimental range (2.16.840.1.114027.80.9.1.*) to official IANA-assigned range (1.3.6.1.5.5.7.6.*) - `Oids.cs`: Update all Composite ML-DSA OID constants to new range - `CompositeMLDsaManaged.cs`: Add "ECDSA" to domain separation strings (e.g., "COMPSIG-MLDSA65-P256-SHA512" → "COMPSIG-MLDSA65-ECDSA-P256-SHA512") - Test data and helpers: Update to reflect new OIDs and domain strings # Customer Impact Without these fixes, Composite ML-DSA keys generated in .NET 10 would not conform to Draft 12 and Draft 13 of the IETF spec, causing interoperability failures with other implementations following the updated standards. # Regression No. This updates implementation to match spec evolution from Draft 8 to Draft 13. # Testing All 1,015 CompositeMLDsa tests pass. Added test coverage for: - Wrong curve OID rejection - Missing parameters rejection - Implicit curve parameters rejection - Explicit curve parameters rejection - Correct parameter serialization for all supported curves - New OID and domain string validation # Risk Low. Changes are confined to Composite ML-DSA implementation (preview feature). Validates existing behavior is maintained while adding required spec compliance. Breaking changes are intentional and necessary for spec conformance. <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Pranav Senthilnathan <pranas@microsoft.com> Co-authored-by: Kevin Jones <vcsjones@github.com>
…SHA-1 (dotnet#121665) Backport of dotnet#121450 to release/10.0 cc @bartonjs ## Customer Impact These are test only changes. These changes react to more environments in CI rejecting certificate chains that use an RSA+SHA-1 root certificate. - [ ] Customer reported - [x] Found internally ## Regression - [ ] Yes - [x] No ## Testing Tests that were failing are now passing in CI. ## Risk None, test only changes.
…eference for net47+ builds.
BryanAldrich
requested review from
BrzVlad,
MichalStrehovsky,
akoeplinger,
ilonatommy,
kotlarmilos,
lateralusX,
lewing,
maraf,
marek-safar,
mdh1418,
noahfalk,
pavelsavara,
sbomer,
steveisok,
thaystg and
vitek-karas
as code owners
github-actions
bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
bot
added
linkable-framework
Contributor
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
Author
|
@dotnet-policy-service agree |
Author
|
fixes #121539 |
Member
|
You are merging commits from wrong branches. Contribution should be edited from the The proposed change won't work either. I'm going to close this. Please help to investigate in the original issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
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.
The ValueTuple package provides an empty DLL for net4.7 and no DLL for net 4.7.1+
This change explicitly adds net47 to the targetFrameworks, then removes the ValueTuple package reference for those applicable builds.