Merge main to feature/const-generics - #3
Merged
Merged
Conversation
* [AndroidAppBuilder] add missing includes to template Treat missing protoype warnings as errors so this doesn't happen again. Fixes dotnet#69601 * also fixup library mode template
… Regex (dotnet#89205) SearchValues has been updated to have an ASCII fast-path for inputs that are not only ASCII. This means we can simplify TryFindNextPossibleStartingPosition in Regex to not track AsciiSet specially and instead just increase the number of characters we query the set for (from 5 to 128). That way, we'll use SearchValues rather than emitting our own helper up until a (semi-arbitrary) point where we deem it impossible or infeasible to enumerate all the chars that make up the set.
* SBLK_MASK_LOCK_THREADID allow tid up to 65535 * copy comment from NativeAOT ObjectHeader.cs --------- Co-authored-by: dickens <dickens.tam@pulsartradingcap.com>
…#89135) Move performance repo clone to before the csproj update and pull out the BDNVersion value from the performance Versions.props.
… parameter or struct field (dotnet#85734) * Do not remove CAST nodes on assignment if the LCL_VAR is a parameter. * Added NormalizeOnLoad rules from SingleAccretion. Added description of why we cannot remove CAST nodes from parameters. * Remove morph optimization for NormalizeOnLoad in fgMorphLocalVar. Update test. * Do not OptimizeCastOnStore for params and struct fields * Update src/coreclr/jit/morph.cpp Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com> * Formatting --------- Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
…9231) MonoMemPool does not support multithreaded allocation. We lock on default jit_mm lock for convenience, since it is widely used in interpreter. We might want to consider using a separate lock.
…#89235) * Update dependencies from https://github.com/dotnet/arcade build 2023071.2 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.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions From Version 8.0.0-beta.23364.2 -> To Version 8.0.0-beta.23369.2 Dependency coherency updates Microsoft.DotNet.XliffTasks From Version 1.0.0-beta.23360.1 -> To Version 1.0.0-beta.23368.1 (parent: Microsoft.DotNet.Arcade.Sdk * Update dependencies from https://github.com/dotnet/xharness build 20230720.1 Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Common , Microsoft.DotNet.XHarness.TestRunners.Xunit From Version 8.0.0-prerelease.23363.3 -> To Version 8.0.0-prerelease.23370.1 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Fixes dotnet#86178 AssemblyUnloadStarted event is now being fired
The access of the target instance was incorrectly inserted right after the location of the delegate instance. Since this indirection can throw a NRE this is incorrect; to get the proper inlined behavior, the indirection must happen only after all arguments have been evaluated. Fix dotnet#75832
Hoisting relies on being able to look at which memory dependencies a candidate is dependent upon. VN tracks these during the map select logic; however, it fails to do so when the map selection hits the cache. This changes the logic to make sure the memory dependencies are cached. Fix dotnet#75442
* UnsafeAccessors are limited to lookup on the defined typed. * Update documentation for attribute. --------- Co-authored-by: vitek-karas <10670590+vitek-karas@users.noreply.github.com>
* Use RegDeleteTree in RegistryKey.DeleteSubKeyTree * Restore self delete behavior * Call RegDeleteTree on subkey to simulate permission behavior. * Adjust comment and add tests.
illink dropped the exclude feature functionality, so will we. I believe Unity was the last user of these tests so it's safe to delete them now.
* Vectorize Enumerable.Range initialization * Address PR feedback --------- Co-authored-by: Stephen Toub <stoub@microsoft.com>
…rms (dotnet#86089) The Helix payload is generated using the runtime pipeline. Then, the libraries pipeline is utilized to AOT compile and execute the tests on Helix. The build-runtime-tests-and-send-to-helix.yml is updated with the compileOnHelix parameter, which if set, uses the libraries/helix.yml template instead of the runtime send-to-helix-step.yml template. The runtime and libraries pipelines are updated to support AOT compilation of runtime tests on Helix.
* Move full facade assemblies into src/libraries/shims Fixes dotnet#78978 1. Move all full facade assemblies (which only contain type forwards) into src/libraries/shims. 2. Merge assemblies (ref+src) which typeforward to the same destination. 3. They inherently now don't produce a documentation file anymore (as shims only contain type forwards). This minimizes the build graph (makes the libs build faster) and moves the focus away from full facade assemblies that need to be kept for compat reasons. * Trigger CI for all legs * Remove obsolete slns and undo CI change * PR feedback from Eric * Change System.ValueTuple type fowrard dest * Collapse ref and src shims further As discussed with Eric offline, typeforwarding to System.Runtime and System.Xml.ReaderWriter makes it possible to collapse the following ref and src projects into just src: System.AppContext System.Buffers System.Diagnostics.Debug System.Diagnostics.Tools System.Globalization System.Globalization.Calendars System.IO.UnmanagedMemoryStream System.Reflection System.Resources.ResourceManager System.Runtime.CompilerServices.Unsafe System.Runtime.Extensions System.Security.Principal System.Text.Encoding System.Threading.Timer System.Xml.XmlDocument The destination then handles the type fowarding to the private assembly implementation.
…e are being used. (dotnet#89199) * Emit a diagnostic when attributes deriving from JsonConverterAttribute are being used. * Address feedback.
* Support for utf conversion * cast fix * FB * FB * Update src/coreclr/nativeaot/Runtime/eventpipe/ep-rt-aot.h Co-authored-by: Jan Kotas <jkotas@microsoft.com> * Apply suggestions from code review Co-authored-by: Jan Kotas <jkotas@microsoft.com> * FB * FB * FB --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com>
`--exclude-feature` logic was removed. If there is no intent to support this with coreclr bcl then we won't worry about it either. While we do need UnityLinker to continue to handle mono class libraries for awhile longer, the `--exclude-feature` functionality is a niche thing we can drop now.
Filters are run during the first pass of EH which makes determining their successors complicated, and the JIT did not get this right. In particular, after running filters as part of first-pass EH, control may flow to any enclosed finally or fault handler as part of second-pass EH. Thus, these should be considered as EH successors. This adds a BasicBlock::VisitEHSecondPassSuccs to visit these successors. The logic was mostly extracted from liveness that (almost) got it right: there was a condition that meant the logic did not run for top-level try-filter clauses. This change folds in Bruce's change to fix this scenario as well. There was one more bug in the logic in liveness: to determine the enclosed fault/finally blocks, the logic iterates backwards in the EH table while looking for enclosed clauses. However, this was only checking for clauses enclosed in the try region when it should also check for clauses enclosed in the handler region. Fix dotnet#86538 Fix dotnet#88168 Co-authored-by: Bruce Forstall <brucefo@microsoft.com>
With PGO and (via dotnet#88749) one level of recursive inlining enabled, the jit sees the recursive call made by `IntroSort` as an attractive inline candidate, but it isn't. Fixes dotnet#89106.
* [RISC-V][JIT] Fix canonical NaN issue * [RISC-V][JIT] Update to use helpers * [RISC-V][JIT] Update conversion functions * [RISC-V][JIT] Update
* Fix TestGenericAddStaticField * use the correct Method Table to gather fields
This was added in dotnet#85743 (comment). Setting this flag is not the right thing to do. It sweeps issues under the carpet. Also, we're only doing it for signature type variables, not method variable. And since no tests seem to be failing, it might not even be necessary.
The extra size appears to be the export list, which is zeroed but not removed when the file is stripped. Exes shouldn't have any exported symbols by default, but ld will include everything by default. We'll fix it up using an ld flag. Fixes dotnet#86707
We were computing these as the minimum object size. This number is meaningless because they don't get allocated on the GC heap. A zero compresses better. Surprisingly saves like 0.1% on Hello World despite being such an insignificant thing.
hez2010
pushed a commit
that referenced
this pull request
Jun 9, 2024
…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```
jkotas
pushed a commit
that referenced
this pull request
Sep 8, 2024
* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug dotnet#7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)
hez2010
pushed a commit
that referenced
this pull request
Oct 18, 2025
Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`
hez2010
pushed a commit
that referenced
this pull request
May 15, 2026
…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixes dotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
hez2010
pushed a commit
that referenced
this pull request
Jun 11, 2026
An Android production app reported a native abort while building an X.509 chain on arm64. The available tombstone snippet showed the process aborting in `AndroidCryptoNative_X509ChainBuild` from `pal_x509chain.c`, with the native guard reporting that parameter `ctx` was not a valid pointer. The report did not include a repro or full tombstone, but the observed failure mode means managed code reached the native build entry point with a null `X509ChainContext*`. ``` Thread /__w/1/s/src/native/libs/System.Security.Cryptography.Native.Android/pal_x509chain.c:113 (AndroidCryptoNative_X509ChainBuild): Parameter 'ctx' must be a valid pointer *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** pid: 0, tid: 31609 >>> com.app.name <<< backtrace: #00 pc 0x000000000002232c /system/lib64/libc.so (abort+116) #1 pc 0x0000000000021fe8 [removed]-KwPZdoEumri00C7kBm3pQw==/lib/arm64/libSystem.Security.Cryptography.Native.Android.so #2 pc 0x00000000000220b0 [removed]-KwPZdoEumri00C7kBm3pQw==/lib/arm64/libSystem.Security.Cryptography.Native.Android.so (AndroidCryptoNative_X509ChainBuild+88) #3 pc 0x000000000000cfcc ``` `X509ChainContext` is created by `AndroidCryptoNative_X509ChainCreateContext`. That initialization can fail if Android certificate store setup or PKIX parameter construction throws, or if required JNI global references cannot be created. Previously, the managed Android chain path stored the returned `SafeHandle` without checking whether context creation failed, so a later build could pass a null native context to `AndroidCryptoNative_X509ChainBuild` and terminate the app process. This change makes context creation fail gracefully: - The native create path checks Java exceptions around object creation and method calls more consistently. - Partial native contexts are destroyed if global-reference creation fails. - The Android interop wrapper checks the returned chain context immediately, including a null safe-handle return, and throws `CryptographicException` if initialization failed. No regression test is included because the reliable failure modes depend on Android platform/provider state or artificial fault injection, and a test hook would be fragile and not representative. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Kevin Jones <kevin@vcsjones.com>
hez2010
pushed a commit
that referenced
this pull request
Jul 26, 2026
…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9
hez2010
pushed a commit
that referenced
this pull request
Jul 26, 2026
…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.