Skip to content

Resolve ILVerify errors — adjust codegen (551 → 56 errors) - #19372

Merged
T-Gro merged 24 commits into
mainfrom
eng/tackle-ilverify-errors
Mar 10, 2026
Merged

Resolve ILVerify errors — adjust codegen (551 → 56 errors)#19372
T-Gro merged 24 commits into
mainfrom
eng/tackle-ilverify-errors

Conversation

@T-Gro

@T-GroT-Gro commented Mar 2, 2026

Copy link
Copy Markdown
Member

For a long time, the F# compiler was producing IL code that did not pass ILVerify. This time ends now :)

This PR fixes the vast majority of ILVerify errors across FSharp.Compiler.Service and FSharp.Core (551 → 56), by adjusting IL codegen in 5 targeted waves. The 56 remaining errors are all native pointer / unmanaged memory operations (NativePtr, RawByteMemory, castToString, retype) — inherently unverifiable by design.

Each codegen change includes benchmarks comparing code compiled by the local (patched) compiler vs the SDK compiler, confirming no runtime regressions.


Wave 1: Specialized stelem/ldelem for primitive types (ilwrite.fs)

Problem: The IL writer emitted stelem <TypeToken> / ldelem <TypeToken> for primitive array element types (bool, char, int32, etc.). ILVerify's type verification treats the loaded/stored values as the verification type of the token, which for small integers like bool and char differs from the stack representation. This causes StackUnexpected errors.

Fix: Map primitive ILTypes to their corresponding ILBasicType and emit specialized instructions (stelem.i4, ldelem.u2, etc.) which have well-defined verification semantics. This is the largest single wave — it eliminated errors across the entire compiler and FSharp.Core.

Files:src/Compiler/AbstractIL/ilwrite.fs

Wave 2a: callvirtcall on value types (IlxGen.fs)

Problem: The codegen emitted callvirt for method calls on unboxed value types (e.g., struct.GetHashCode()). ECMA-335 requires call or constrained callvirt for value type methods — plain callvirt is invalid on an unboxed value type receiver.

Fix: Guard callvirt emission with boxity <> AsValue in both GenApp and GenILCall, falling through to call for value types.

Files:src/Compiler/CodeGen/IlxGen.fs

Wave 2b: castclass at interface join points (IlxGen.fs)

Problem: When a match expression returns an interface type and branches produce different concrete classes, the IL verifier computes the LUB of the concrete types at the join point as System.Object instead of the interface. This causes StackUnexpected at the consumer of the join point result.

Fix: Introduce a CastThenBr sequel that emits castclass to the interface type before branching to the join label. Applied only when the result type is an interface and all branches produce reference types.

Files:src/Compiler/CodeGen/IlxGen.fs

Wave 3: Filter → catch inside finally/fault handlers (IlxGen.fs)

Problem:try/with using a when guard inside a finally block emitted a filter block nested inside the finally handler. ILVerify (incorrectly) computes the entry stack for such a filter as empty (the finally entry) instead of having the exception object on stack, causing StackUnderflow. See dotnet/runtime#112406.

Fix: Track insideFinallyOrFaultHandler in the codegen environment and suppress filter block emission inside finally/fault handlers, falling back to a catch-based pattern instead.

Files:src/Compiler/CodeGen/IlxGen.fs

Wave 4: Witness field alignment in state machine structs (IlxGen.fs)

Problem:GenStructStateMachine initialized closure fields by zipping cloFreeVars with ilCloAllFreeVars. When SRTP witnesses are present, ilCloAllFreeVars has witness fields prepended, so the zip was misaligned — witness fields got regular free var values and vice versa. This produced type mismatches (StackUnexpected) in task { let! ... and! ... } expressions.

Fix: Initialize witness fields separately (first N entries of ilCloAllFreeVars), then zip the remaining entries with cloFreeVars.

Files:src/Compiler/CodeGen/IlxGen.fs


ILVerify error count

BaselineBeforeAfter
FSharp.Compiler.Service Debug net10.07311
FSharp.Compiler.Service Debug netstandard2.09811
FSharp.Compiler.Service Release net10.09912
FSharp.Compiler.Service Release netstandard2.012512
FSharp.Core Debug netstandard2.0425
FSharp.Core Debug netstandard2.1425
FSharp.Core Release netstandard2.0360
FSharp.Core Release netstandard2.1360
Total55156

Remaining 56 errors are all Unmanaged pointers are not a verifiable type / StackUnexpected on retype/castToString/castclassPrim/iscastPrim/notnullPrim — intrinsically unverifiable operations.

Benchmark results (LocalCompiler = this PR, SdkCompiler = baseline)

No regression: stelem/ldelem (0.99–1.03, within noise), task CEs, callvirt→call (StructToString, StructEquals, StructInDictionary)
Slight improvement: callvirt→call on GetHashCode (0.93–0.96), CastThenBr on interface match (0.88–0.95), filter→catch on exception paths (0.93–0.96)
Slight regression: filter→catch on no-exception path (1.06)

Full BenchmarkDotNet output

BenchmarkDotNet v0.13.10, macOS 26.2 (25C56) [Darwin 25.2.0]
Apple M3 Max, 1 CPU, 16 logical and 16 physical cores
.NET SDK 10.0.101
[Host] : .NET 10.0.1 (10.0.125.57005), Arm64 RyuJIT AdvSIMD DEBUG
LocalCompiler : .NET 10.0.2 (10.0.225.61305), Arm64 RyuJIT AdvSIMD
SdkCompiler : .NET 10.0.2 (10.0.225.61305), Arm64 RyuJIT AdvSIMD
Arguments=/p:BUILDING_USING_DOTNET=true 
TypeMethodJobMeanErrorStdDevMedianP95RatioRatioSDGen0Gen1AllocatedAlloc Ratio
CallVirtOnValueTypeBenchmarkStructGetHashCodeLocalCompiler3,011.739 ns4.1497 ns3.8816 ns3,011.152 ns3,018.224 ns1.000.00---NA
CallVirtOnValueTypeBenchmarkStructGetHashCodeSdkCompiler3,020.885 ns3.4751 ns2.9019 ns3,021.219 ns3,024.821 ns1.000.00---NA
CastThenBrBenchmarkMatchReturningInterface_NoAllocLocalCompiler23,985.794 ns475.2417 ns794.0221 ns23,652.795 ns25,443.705 ns0.880.06---NA
CastThenBrBenchmarkMatchReturningInterface_NoAllocSdkCompiler27,398.117 ns543.5979 ns1,432.0542 ns27,033.290 ns30,303.813 ns1.000.00---NA
FilterInFinallyBenchmarkTryWithInFinally_NoExceptionLocalCompiler555.539 ns10.4836 ns17.2249 ns548.821 ns586.716 ns1.060.04---NA
FilterInFinallyBenchmarkTryWithInFinally_NoExceptionSdkCompiler530.672 ns1.7119 ns1.4295 ns530.475 ns533.055 ns1.000.00---NA
StelemLdelemBenchmarkBoolArrayReadWriteLocalCompiler3,589.626 ns24.9488 ns20.8334 ns3,587.869 ns3,625.366 ns1.020.01---NA
StelemLdelemBenchmarkBoolArrayReadWriteSdkCompiler3,513.090 ns40.1561 ns37.5620 ns3,536.126 ns3,547.690 ns1.000.00---NA
TaskMergeSourcesBenchmarkTaskLetBangAndBangLocalCompiler14.754 ns0.2272 ns0.2125 ns14.692 ns15.123 ns1.000.020.0004-72 B1.00
TaskMergeSourcesBenchmarkTaskLetBangAndBangSdkCompiler14.751 ns0.0665 ns0.0589 ns14.737 ns14.860 ns1.000.000.0004-72 B1.00
CallVirtOnValueTypeBenchmarkStructToStringLocalCompiler6,550.059 ns30.8829 ns28.8879 ns6,552.014 ns6,596.813 ns1.000.000.1678-27960 B1.00
CallVirtOnValueTypeBenchmarkStructToStringSdkCompiler6,522.629 ns22.4117 ns17.4976 ns6,524.147 ns6,548.854 ns1.000.000.1678-27960 B1.00
CastThenBrBenchmarkMatchReturningInterface_AllocLocalCompiler57,340.381 ns566.1241 ns501.8542 ns57,160.351 ns58,333.448 ns1.020.011.5869-266456 B1.00
CastThenBrBenchmarkMatchReturningInterface_AllocSdkCompiler56,407.777 ns807.8752 ns755.6869 ns56,003.489 ns57,572.996 ns1.000.001.5869-266456 B1.00
FilterInFinallyBenchmarkTryWithInFinally_WithExceptionLocalCompiler2,140,943.877 ns42,143.2213 ns51,755.6605 ns2,130,150.148 ns2,226,091.349 ns0.930.07--216000 B1.00
FilterInFinallyBenchmarkTryWithInFinally_WithExceptionSdkCompiler2,262,674.964 ns56,794.0958 ns151,594.9387 ns2,201,999.594 ns2,728,839.813 ns1.000.00--216003 B1.00
StelemLdelemBenchmarkIntArrayReadWriteLocalCompiler2,884.971 ns9.4347 ns8.3636 ns2,885.090 ns2,896.610 ns1.030.00---NA
StelemLdelemBenchmarkIntArrayReadWriteSdkCompiler2,812.112 ns6.3549 ns5.3067 ns2,811.917 ns2,820.260 ns1.000.00---NA
TaskMergeSourcesBenchmarkTaskLetBangAndBang3LocalCompiler27.341 ns0.3246 ns0.2711 ns27.374 ns27.714 ns1.010.010.0009-152 B1.00
TaskMergeSourcesBenchmarkTaskLetBangAndBang3SdkCompiler27.020 ns0.2093 ns0.1748 ns27.045 ns27.238 ns1.000.000.0009-152 B1.00
CallVirtOnValueTypeBenchmarkStructEqualsLocalCompiler29,573.711 ns220.8120 ns206.5476 ns29,562.723 ns29,922.468 ns1.010.021.4343-239976 B1.00
CallVirtOnValueTypeBenchmarkStructEqualsSdkCompiler29,420.301 ns390.6764 ns365.4390 ns29,608.037 ns29,790.980 ns1.000.001.4343-239976 B1.00
CastThenBrBenchmarkMatchReturningIComparableLocalCompiler91,689.908 ns369.9182 ns308.8985 ns91,709.345 ns92,134.706 ns0.950.040.8545-159264 B1.00
CastThenBrBenchmarkMatchReturningIComparableSdkCompiler95,445.088 ns1,708.9753 ns3,413.0083 ns93,995.697 ns103,541.611 ns1.000.000.8545-159264 B1.00
FilterInFinallyBenchmarkTryWithInFinally_GuardHitLocalCompiler1,972,895.145 ns8,926.4190 ns7,453.9641 ns1,969,982.098 ns1,984,866.016 ns0.960.01--224000 B1.00
FilterInFinallyBenchmarkTryWithInFinally_GuardHitSdkCompiler2,068,823.482 ns26,346.7064 ns24,644.7255 ns2,058,629.232 ns2,102,062.206 ns1.000.00--224001 B1.00
StelemLdelemBenchmarkCharArrayReadWriteLocalCompiler3,837.618 ns7.9594 ns6.6464 ns3,834.811 ns3,848.598 ns0.990.00---NA
StelemLdelemBenchmarkCharArrayReadWriteSdkCompiler3,884.815 ns19.1506 ns15.9916 ns3,878.658 ns3,914.045 ns1.000.00---NA
TaskMergeSourcesBenchmarkTaskLetBangSequentialLocalCompiler5.368 ns0.1307 ns0.1790 ns5.324 ns5.703 ns1.000.06---NA
TaskMergeSourcesBenchmarkTaskLetBangSequentialSdkCompiler5.382 ns0.1341 ns0.1435 ns5.359 ns5.664 ns1.000.00---NA
CallVirtOnValueTypeBenchmarkStructInDictionaryLocalCompiler12,207.604 ns142.8089 ns133.5836 ns12,157.128 ns12,412.242 ns1.000.010.68660.0916111648 B1.00
CallVirtOnValueTypeBenchmarkStructInDictionarySdkCompiler12,189.143 ns148.7887 ns165.3783 ns12,107.841 ns12,486.912 ns1.000.000.68660.0916111648 B1.00
FilterInFinallyBenchmarkSimpleTryFinallyLocalCompiler530.156 ns1.2822 ns1.0707 ns530.444 ns531.379 ns0.960.01---NA
FilterInFinallyBenchmarkSimpleTryFinallySdkCompiler552.759 ns10.7679 ns8.9917 ns548.853 ns569.225 ns1.000.00---NA
StelemLdelemBenchmarkSByteArrayReadWriteLocalCompiler5,512.868 ns28.2968 ns26.4689 ns5,510.768 ns5,560.457 ns0.990.01---NA
StelemLdelemBenchmarkSByteArrayReadWriteSdkCompiler5,576.221 ns76.5248 ns63.9016 ns5,575.136 ns5,679.119 ns1.000.00---NA
TaskMergeSourcesBenchmarkTaskSimpleLocalCompiler6.829 ns0.0918 ns0.0859 ns6.832 ns6.976 ns1.010.020.0004-72 B1.00
TaskMergeSourcesBenchmarkTaskSimpleSdkCompiler6.746 ns0.1331 ns0.1112 ns6.704 ns6.943 ns1.000.000.0004-72 B1.00
CallVirtOnValueTypeBenchmarkIntGetHashCodeLocalCompiler2,504.634 ns6.6625 ns5.9061 ns2,503.363 ns2,513.041 ns0.930.00---NA
CallVirtOnValueTypeBenchmarkIntGetHashCodeSdkCompiler2,692.462 ns6.0291 ns5.3446 ns2,692.454 ns2,700.421 ns1.000.00---NA
StelemLdelemBenchmarkByteArrayReadWriteLocalCompiler3,827.056 ns20.1288 ns16.8085 ns3,833.095 ns3,837.618 ns1.020.00---NA
StelemLdelemBenchmarkByteArrayReadWriteSdkCompiler3,742.817 ns8.5823 ns7.1666 ns3,745.259 ns3,752.045 ns1.000.00---NA
CallVirtOnValueTypeBenchmarkDateTimeGetHashCodeLocalCompiler2,629.997 ns38.8126 ns34.4064 ns2,637.633 ns2,670.062 ns0.960.01---NA
CallVirtOnValueTypeBenchmarkDateTimeGetHashCodeSdkCompiler2,724.887 ns10.5121 ns8.7781 ns2,720.738 ns2,741.800 ns1.000.00---NA
StelemLdelemBenchmarkIntArrayFilterToArrayLocalCompiler7,796.051 ns23.8529 ns21.1450 ns7,796.818 ns7,825.524 ns0.990.010.1221-21296 B1.00
StelemLdelemBenchmarkIntArrayFilterToArraySdkCompiler7,882.273 ns125.4244 ns111.1855 ns7,827.736 ns8,067.406 ns1.000.000.1221-21296 B1.00
StelemLdelemBenchmarkBoolArrayCountTrueLocalCompiler2,800.847 ns17.0188 ns15.0868 ns2,796.306 ns2,828.988 ns1.000.01---NA
StelemLdelemBenchmarkBoolArrayCountTrueSdkCompiler2,809.914 ns22.2283 ns20.7924 ns2,801.633 ns2,849.625 ns1.000.00---NA

T-Groand others added 9 commits March 2, 2026 10:27
When emitting IL for I_stelem_any and I_ldelem_any with primitive
element types (bool, byte, char, int16, int32, etc.), emit the
specialized instructions (stelem.i1, stelem.i4, ldelem.u1, etc.)
instead of the generic stelem <T> / ldelem <T> form.
This matches C# compiler behavior and eliminates 306 ILVerify
StackUnexpected errors caused by asymmetric verification type
handling in ILVerify (ECMA-335 §I.8.7).
ILVerify baseline changes:
- FSharp.Core: 32 → 20 errors (Release), 37 → 25 (Debug)
- FSharp.Compiler.Service: 125 → 18 (Release ns2.0), 99 → 18 (net10)
98 → 16 (Debug ns2.0), 73 → 16 (Debug net10)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ange struct GetHashCode
- HashMultiMap: Add explicit :> IDictionary<_,_> upcasts in both branches of
the if/else expressions for firstEntries and rest fields. This causes the
F# compiler to emit castclass at the join point, which ILVerify needs to
see the correct interface type on the stack instead of computing the LUB
of ConcurrentDictionary and Dictionary as System.Object.
- range.fs: Change o.GetHashCode() to (box o).GetHashCode() in the Range
struct IEqualityComparer. Range is a struct, and callvirt on a value type
without a constrained. prefix is flagged by ILVerify as CallVirtOnValueType.
Boxing first makes the callvirt valid on the boxed reference type.
Together these eliminate 5 ILVerify baseline entries (2 HashMultiMap + 1
AssemblyResolveHandler + 1 FSharpChecker + 1 CallVirtOnValueType).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…st and Range struct GetHashCode"
This reverts commit 4614ffe.
… casts
Two codegen fixes to eliminate ILVerify errors:
1. CallVirtOnValueType: In GenApp, prevent emitting callvirt when the
declaring type is a value type (boxity = AsValue). For value types,
callvirt without constrained. prefix is invalid per ECMA-335. This
also applies as a safety net in GenILCall.
2. Interface join point casts: Add CastThenBr sequel that emits
castclass before branching at match/if-else join points when the
result type is an interface. Without this, ILVerify computes the LUB
of different concrete class types as System.Object instead of the
expected interface type. Only applied when all branches produce
reference types (not value types or unit).
Eliminates 5 ILVerify baseline entries per configuration:
- HashMultiMap StackUnexpected x2 (IDictionary join)
- AssemblyResolveHandler StackUnexpected (IDisposable join)
- FSharpChecker StackUnexpected (IBackgroundCompiler join)
- comparer@607 CallVirtOnValueType (Range.GetHashCode)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
ILVerify has a bug where a filter nested inside a finally handler
gets its entry stack computed incorrectly (as empty instead of
[exception_object]). This happens because ILVerify's
FindEnclosingExceptionRegions picks HandlerIndex (the enclosing
finally) instead of FilterIndex when both are set, then uses the
finally's Kind to determine stack state.
The fix adds insideFinallyOrFaultHandler tracking to IlxGenEnv.
When inside a finally handler, GenTryWith emits catch blocks
instead of filter blocks. Semantically identical for catch-all
patterns (filter always returns 1 == catch Exception).
Eliminates the DoWithColor StackUnderflow error:
- FCS Release: 13 -> 12 errors per config
- FCS Debug: 11 -> 10 errors per config (to be verified by CI)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
GenStructStateMachine zipped cloFreeVars (regular free vars only) with
ilCloAllFreeVars (witness fields + regular fields). When witness fields
were present (in $W methods), the zip was misaligned: regular var values
were stored into witness fields and vice versa.
The fix initializes witness fields separately first, then skips them when
zipping with regular free vars.
This was a genuine codegen bug affecting all MergeSources$W methods in
FSharp.Core task computation expressions. The $W state machine struct had
both witness function fields (getAwaiter, getResult, get_IsCompleted) and
regular value fields (computation, task), but the initialization code
stored task values into witness fields due to the array offset mismatch.
Eliminates all 20 FSharp.Core Release ILVerify errors and all 20
MergeSources$W errors from Debug baselines.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
BDN benchmarks for each IL codegen change:
- StelemLdelem: primitive array read/write (ldelem.u1, stelem.i4, etc.)
- CallVirtOnValueType: struct GetHashCode/ToString/Equals (call vs callvirt)
- CastThenBr: match returning interface types (castclass at join points)
- FilterInFinally: try/with inside finally (catch vs filter)
Results: no regressions. callvirt→call shows 4-7% improvement for
struct method calls. All other changes performance-neutral.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@T-Gro
T-Groforce-pushed the eng/tackle-ilverify-errors branch from 6cf2d68 to 8d4513dCompareMarch 2, 2026 09:29
@github-actions

github-actionsBot commented Mar 2, 2026

Copy link
Copy Markdown
Contributor

❗ Release notes required


✅ Found changes and release notes in following paths:

Change pathRelease notes pathDescription
src/Compilerdocs/release-notes/.FSharp.Compiler.Service/11.0.100.md

@T-GroT-Gro changed the title Resolve ilverify errors - adjust codegenResolve ILVerify errors — adjust codegen (551 → 56 errors)Mar 2, 2026
T-Groand others added 2 commits March 2, 2026 10:43
- TailCall 06: Update IL offsets (IL_0040→IL_0034) due to stelem.i4 being shorter
- ILVerify Debug baselines: Fix set_Item offset (0x1F→0x25), normalize pointerToNativeInt
- ILVerify script: Handle empty baseline matching empty output (FSharp.Core Release)
- StructDU net472 baseline: callvirt→call on value type ToString()
- Trimming check: Update expected FSharp.Core.dll size (311296→311808)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@vzarytovskii

Copy link
Copy Markdown
Member

Nice, finally!

@github-project-automationgithub-project-automationBot moved this from New to In Progress in F# Compiler and ToolingMar 2, 2026
@vzarytovskii

Copy link
Copy Markdown
Member

IIRC (I don't have data to support that, only old discussions I had with Don and Kevin), exception filters resluted in some worse runtime perf on old runtimes, not sure if we care or care to confrim/deny that.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@T-Gro

T-Gro commented Mar 2, 2026

Copy link
Copy Markdown
MemberAuthor

It was for mono.
The F.C.S itself is using them in the last 1-2 stable versions without complaints.

(i.e. no reported problems on the environments where people run the compiler/SDK. Which of course does not mean all environments where the compiled code can run)

UPDATE: The filter blocks are only default for the compiler itself, it is a compiler switch. Changing it to be come default for all users is a different story, not done here.

@T-Gro
T-Gro marked this pull request as ready for review March 2, 2026 16:55
@T-Gro
T-Gro requested a review from a team as a code ownerMarch 2, 2026 16:55
@T-Gro
T-Gro enabled auto-merge (squash) March 6, 2026 11:02
T-Groand others added 6 commits March 6, 2026 18:28
…ing release note
Update SelfContained_Trimming_Test expected size from 311808 to 310784 bytes
to match the actual trimmed output after merging main.
Restore the culture-independent parsing release note entry (PR #19370) that
was dropped during the merge conflict resolution.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…rrors
# Conflicts:
#	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md
AsyncLocal cancellation token cleanup may not have propagated after
Async.RunSynchronously on slower CI platforms. Add tolerance delay
before the HasCancellationToken assertion, matching the same pattern
needed for MacOS CI.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Gro added a commit that referenced this pull request Mar 6, 2026
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Gro added a commit that referenced this pull request Mar 6, 2026
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Groand others added 2 commits March 8, 2026 21:14
@T-Gro
T-Gro merged commit 7981cb5 into mainMar 10, 2026
45 checks passed
@github-project-automationgithub-project-automationBot moved this from In Progress to Done in F# Compiler and ToolingMar 10, 2026
T-Gro added a commit that referenced this pull request Mar 13, 2026
Resolve merge conflicts with main after PR #19372 (ILVerify fixes):
- Release notes: keep both PR's and #19372's entries
- ILVerify baselines: regenerated from clean builds
- CodeGenRenamings01 BSL: regenerated from clean build
- ForLoop, SeqExpressionStepping, AsyncExpressionStepping,
ComputationExpressions, TestFunction24 BSLs: auto-merged
successfully, verified by test runs
All tested locally - Debugger, ForLoop, SeqExpressionStepping,
AsyncExpressionStepping, ComputationExpressions, TestFunction24
tests pass.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Gro added a commit that referenced this pull request Mar 13, 2026
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Gro added a commit that referenced this pull request Mar 16, 2026
- Merge origin/main to resolve conflicts (auto-merged cleanly)
- Remove duplicate PR #19372 release-notes entry from merge
- CI failure (AsyncType.StartAsTaskCancellation) is known flaky, unrelated to PR
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

3 participants

@T-Gro@vzarytovskii@abonie