[browser] Move boot config tests to Wasm.Build.Tests by maraf · Pull Request #131199 · dotnet/runtime

maraf · 2026-07-22T10:09:50Z

Follow-up to #130825: move boot config test coverage into Wasm.Build.Tests and remove the temporary tasks.tests project.

Changes:

add GenerateWasmBootJsonTests under src/mono/wasm/Wasm.Build.Tests
add [TestCategory("no-workload")] to the moved test class
delete src/tasks.tests/Microsoft.NET.Sdk.WebAssembly.Pack.Tasks.Tests project and test file
remove obsolete InternalsVisibleTo entry from Microsoft.NET.Sdk.WebAssembly.Pack.Tasks.csproj

Note

This PR description was generated with GitHub Copilot assistance.

Spec: https://json-schema.org/draft/2020-12/draft-bhutton-json-schema-validation-01#section-9.3

Reverts the DEBUG-only free-threaded assert added to `FreeThreadedStrategy` in #130906. The assert was overly strict: `FreeThreadedStrategy` is also valid for apartment-affinitized COM objects when the current thread already has the correct apartment type, so the agility probe produced false assert failures. Also clarifies documentation on `StrategyBasedComWrappers.DefaultIUnknownStrategy` and adds a class comment on `FreeThreadedStrategy` describing these use cases.

Adds a `DacDbiInterfaceInstance` entrypoint to the cDAC (mscordaccore_universal) so DBI can obtain an `IDacDbiInterface` backed by the managed data-contract reader, mirroring the native DAC export of the same name and signature. Previously the cDAC only exposed the SOS / `IXCLRDataProcess` surface via `CLRDataCreateInstance`, so DBI could only be serviced through the native DAC. ## What this enables - A cDAC-serviced DacDbi creation path with the export name and signature DBI already expects. - The supporting interop declarations the entrypoint needs: `ICorDebugDataTarget` and `ICLRRuntimeLocator`. ## Design decisions and tradeoffs - Self-location via the contract descriptor: the cDAC builds its target from the embedded contract descriptor (read through `ICLRContractLocator` on the caller's data target). The passed runtime base is used only to cross-check against `ICLRRuntimeLocator::GetRuntimeBase` when the data target implements it, keeping the activation model consistent with the SOS path. - The target is read-only: the write-memory path returns `E_NOTIMPL`, which is sufficient for the DacDbi surface. - `DacSetTargetConsistencyChecks` returns success on the standalone path since it only toggles target assertions. Includes unit tests for the consistency-checks toggle. > [!NOTE] > This description was drafted with GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

The wasm `HardwareIntrinsics` tests (`src/tests/JIT/HardwareIntrinsics/Wasm`) are gated by `HWITestsWasmOnly` -> `CLRTestTargetUnsupported` unless `TargetArchitecture == wasm` (plus an `EnableWasmHWIntrinsicsTests` opt-in). As a result, none of the existing PR-triggered intrinsics pipelines ever compile them: - `runtime-coreclr hardware-intrinsics` (`src/coreclr/jit/**`, x86/x64/arm/osx) passes without building the wasm tree. - `hardware-intrinsics-arm64` (`src/coreclr/jit/*arm64*`) is skipped for wasm-only changes. So a break in the wasm intrinsic tests only surfaces in a rolling/outerloop browser-wasm build, which is what required the #130962 follow-up to #130850. ---------- This adds a wasm counterpart mirroring `hardware-intrinsics-arm64.yml`: - `eng/pipelines/coreclr/hardware-intrinsics-wasm.yml` -- PR-triggered, filtered on `src/coreclr/jit/*wasm*` (covers `hwintrinsic*wasm*`, `lowerwasm.cpp`, `regallocwasm.cpp`) plus `src/tests/JIT/HardwareIntrinsics/Wasm/**`. Runs a `browser_wasm` leg with `/p:EnableWasmHWIntrinsicsTests=true -tree:JIT/HardwareIntrinsics/Wasm`. - `eng/pipelines/coreclr/templates/jit-hardware-intrinsics-wasm.yml` -- modeled on the existing `wasi-wasm-coreclr-runtime-tests.yml` (`global-build-job`, `runtimeFlavor: coreclr`, `-s clr+libs+packs`). It is build-only (`sendToHelix: false`) since browser/V8 can''t execute these tests yet -- enough to catch compile breaks like #130962. Like `hardware-intrinsics-arm64.yml`, the new pipeline still needs an Azure DevOps definition registered against the YAML to appear as a PR check. > [!NOTE] > This PR description was drafted by Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…0974) The saturating `float`/`double` -> small integral cast changes from #128604 were not reflected in two outerloop tests, breaking CI (see #130962 (comment)). ---------- `JIT/Regression/CLR-x86-JIT/V1-M10/b05617`: under saturation `conv.u1` of `2.564783e7` now yields `255` (was `214`) and `conv.i1` of `5246667200` yields `127` (was `-1`). Propagating through the stack, the final `conv.u4` constant is updated `4294967086` -> `4294967043` so the test still returns `100`. Mono still truncates, so the test is marked unsupported on Mono, referencing the same tracking issue (#100368) used by the JIT regression test in #128604. ---------- `JIT/IL_Conformance/Convert/TestConvertFromIntegral`: the two checked `ushort.MaxValue -> short` via `Conv_I2` cases now saturate to `short.MaxValue` on CoreCLR instead of truncating to `-1`. Since the result is now runtime-divergent (Mono truncates), they are marked `UnspecifiedBehaviour`, consistent with how every other cross-runtime-divergent float->integral out-of-range case in this file is already handled. This keeps the rest of the file running on Mono. Verified locally against a checked runtime: `b05617` returns `100` and `TestConvertFromIntegral` reports "All tests passed". > [!NOTE] > This PR description was drafted by Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

) For an arm32 direct BL (ARM32_THUMB_BRANCH24), applyRelocs substitutes a placeholder target when the code block lands more than +-16MB from the call target, so the two sides' immediates differ even though both call the same recorded target. Compare the recorded reloc kind and target instead. Also error out when base and diff JITs are the same module (this has burned me a few times). Fixes #130736

Hopefully fixes ``` /Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/11.0.0-beta.26363.117/tools/Microsoft.DotNet.Helix.Sdk.MonoQueue.targets(79,5): error : Helix API does not contain an entry for $(helix_macos_arm64_latest_internal) [/Users/runner/work/1/s/src/libraries/sendtohelixhelp.proj] ``` seen internally in superpmi-collect.

…ls (#130924) ## Summary On `FEATURE_PORTABLE_ENTRYPOINTS` (wasm) R2R, generated code keeps its shadow stack pointer in a local and leaves the `__stack_pointer` global stale. The P/Invoke prolog (`JIT_PInvokeBegin`) normally publishes it before native code runs, but that prolog is **skipped for `SuppressGCTransition` calls**. A native `SuppressGCTransition` callee (emscripten, which uses `__stack_pointer`) then allocates its shadow frame from the stale global — the caller's SP, *above* the R2R frame — and clobbers the caller's address-taken locals. This manifests in R2R exception handling: `FindFirstPassHandler` spills its by-ref `StackFrameIterator`, calls the `SuppressGCTransition` QCall `RhpEHEnumInitFromStackFrameIterator`, the callee clobbers the spilled pointer, and the next `frameIter.ControlPC` read faults with a spurious `NullReferenceException`. EH dispatch can't GC-transition mid-unwind, which is why its QCalls are `SuppressGCTransition` and hit this path. Fixes #130923. ## Fix Publish the shadow SP to the `__stack_pointer` global just before the call, so the callee allocates its shadow frame below the current frame. The publish is net-zero on the wasm operand stack, so it is safe to emit after the call arguments are pushed. The `stackPointer` global handle comes from the `getWasmWellKnownGlobals` JIT-EE API (added in #129717) and is referenced via a `WASM_GLOBAL_INDEX_LEB` relocation, matching the existing `global.get` uses in wasm codegen. ## Validation The bug only *reproduces* with the (not-yet-merged) R2R-on-wasm bring-up stack, so there is no wasm-R2R CI leg on `main` yet. Verified `codegenwasm.cpp` compiles clean in the wasm JIT (`clr.jit`, 0 errors). Behaviorally validated on the R2R-on-wasm prototype: unfixed crashes, fixed passes, plus a byte-identical R2R↔interpreter battery. ## Notes for reviewers - Draft because it cannot be CI-validated on `main` until the R2R-on-wasm consumption path lands. - Depends on the `getWasmWellKnownGlobals` API from #129717 (fixes #129712), now on `main`. - Related bring-up family: #130634. > [!NOTE] > This pull request was authored with the assistance of GitHub Copilot.

The "duplicate attribute" PFX we use in unit tests is notable because it has named keys, keyname000 and keyname001. Windows's PFX loader has a race where if two PFXs with the same named key are loaded concurrently, they may end up sharing the same private key instances. Disposing one of the certificates will remove the keys out from under the other certificate, resulting in a "keyset not found" error. To address this, we make sure the duplicate attribute PFX has to be loaded under a lock. It's only the loading that needs to be locked, not the whole lifetime of the certificate. When the load happens serially, the Windows PFX loader is aware that a key with that name already exists, so it appropriately generates a random name instead. Our tests don't actually care what the imported name ends up being, just what it doesn't end up being.

`CoseKey` async verification accepted signatures with missing or mismatched protected `alg` headers, unlike synchronous verification. - **Validation** - Validate the protected algorithm before async verification. - Apply consistent validation to `CoseSign1Message` and `CoseSignature`. - **Coverage** - Cover missing and mismatched algorithm headers. - Assert matching sync and async behavior. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Kevin Jones <kevin@vcsjones.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

* Add capability for cDAC to read read-write metadata for Edit and Continue scenarios. * Add caching schema for metadata - Under forward execution, metadata caches are not flushed. Metadata cache is updated upon changes to the metadata, as indicated by the metadata generation (for RefEmit) or by the EnC edit counter. - Under potentially backwards execution, metadata caches are flushed. * Streamline docs Fixes #129557 --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>

`Vector2` (`TYP_SIMD8`) and `Vector3` (`TYP_SIMD12`) have no native wasm valtype, so they live as a `v128` with the low 8/12 bytes populated. Previously the wasm JIT bailed out via the `ins_Load`/`ins_Store` NYIs for these types; this implements the split lane load/store sequences instead. The emitted sequences are: - **simd8 load**: `v128.load64_zero 0` - **simd8 store**: `v128.store64_lane 0, lane 0` - **simd12 load**: `local.get addr; v128.load64_zero 0; v128.load32_lane 8, lane 2` - **simd12 store**: tee the value into a `v128` temporary, `v128.store64_lane 0, lane 0` for the low 8 bytes, then re-materialize the address and `v128.store32_lane 8, lane 2` for the upper 4 bytes `v128.load64_zero` fills lanes 0-1 (zeroing the rest); the trailing lane store/load handles bytes 8-11 for the `Vector3` case. ---------- The `TYP_SIMD12` address is forced multiply-used (loads and heap stores re-materialize it for the trailing lane op). The local-to-stack store rewrite (`RewriteLocalStackStore`) produces a `STOREIND(LCL_ADDR, value)` whose address is a re-materializable `GT_LCL_ADDR`, so that case is excluded from multiply-use and codegen re-emits the frame pointer directly. Because that synthesized `STOREIND` is not revisited by the main collection walk, its internal `v128` tee register is requested in `RewriteLocalStackStore`. ---------- Measured on the corelib crossgen2 browser SuperPMI collection (27,540 contexts): hard asserts drop from **403 to 30**, eliminating **373** `SIMD8`/`SIMD12` load/store asserts with no regressions. The residual 30 are the pre-existing `NYIRAW` oper catch-all, unrelated to this change. Full effectiveness requires #130866 (which removes the shadowing SIMD-ABI bailouts for SIMD params/locals/stores/call-args); standalone, this change already clears the 373 asserts above on that collection. > [!NOTE] > This PR description was drafted with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…insics (#130938) ## Summary The internal `System.Runtime.Intrinsics.Wasm.WasmBase` class (already on `main`) declares `LeadingZeroCount`/`TrailingZeroCount` (int/uint/long/ulong) as self-recursive intrinsic stubs, but the RyuJIT-wasm backend left them unimplemented — the WasmBase `IsaRange` was `{ NI_Illegal, NI_Illegal }`, so these fell back to the managed software implementation. This wires the two intrinsics into the RyuJIT-wasm backend so they lower to native wasm `clz`/`ctz`: - **`hwintrinsic.cpp`** — give WasmBase a real IsaRange `{ FIRST_NI_WasmBase, LAST_NI_WasmBase }`. - **`hwintrinsiclistwasm.h`** — add the two scalar `HARDWARE_INTRINSIC` entries (`HW_Category_Scalar`, `HW_Flag_SpecialImport|HW_Flag_NoFloatingPointUsed`), matching the established xarch scalar `LeadingZeroCount`/`TrailingZeroCount` pattern (simdSize `0`). - **`hwintrinsicwasm.cpp`** — special-import each to a `GT_INTRINSIC` over the existing `NI_PRIMITIVE_LeadingZeroCount`/`NI_PRIMITIVE_TrailingZeroCount`, which wasm codegen already lowers to `i32.clz`/`i64.clz` and `i32.ctz`/`i64.ctz` (see `codegenwasm.cpp`). **Consumer:** `System.Numerics.BitOperations` (`LeadingZeroCount`/`Log2`/`TrailingZeroCount`) routes through `WasmBase.LeadingZeroCount(value)` when `WasmBase.IsSupported`. Implementing these makes core bit operations use native wasm `clz`/`ctz` on RyuJIT-wasm instead of the software fallback. ## API review No new or changed public API. `WasmBase` is `internal` and already shipped on `main`; this PR only implements its JIT lowering. No API review required. ## Validation - ✅ **JIT compiles clean.** The wasm cross-JIT (`clrjit_universal_wasm_arm64`) builds with 0 warnings / 0 errors after a full recompile of the changed sources (`clr.jit -c Release`). Baseline `clr+libs -rc Release` and `clr -os browser -c Release` also build clean. - ✅ **Lowering target already exists.** `NI_PRIMITIVE_*ZeroCount` `GT_INTRINSIC` nodes for `TYP_INT`/`TYP_LONG` are already handled by `codegenwasm.cpp` (emits `i32/i64.clz`/`ctz`), so the intrinsics reuse a proven codegen path. - ⚠️ **Runtime execution not verified locally.** Attempting to run under the experimental wasm-CoreCLR `corerun.js` fails at `coreclr_initialize` (`0x80070057`) **even for the pre-built `tieringtest.dll` smoke test** — a pre-existing bring-up limitation of the experimental runtime in this environment (note the `System.Private.CoreLib.NotReadyYet.wasm` artifact), unrelated to this change and occurring before any JIT/intrinsic code runs. Existing `System.Numerics.BitOperations` tests already cover `LeadingZeroCount`/`TrailingZeroCount` for all overloads and will exercise this path once the wasm runtime can execute. Opening as **draft** because end-to-end runtime execution could not be verified locally (blocked by the experimental runtime, not by this change). > [!NOTE] > This pull request was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Removes 16 functions from the CoreCLR xarch emitter that had zero call sites anywhere in the repo. This is a DEBUG/encoding cleanup only -- no behavioral change. Each function's declaration in `emitxarch.h` and definition (with its doc-comment block) in `emitxarch.cpp` was removed, after re-verifying zero callers via `git grep -w <name> -- 'src/coreclr/*'`. Removed: - Prefix/encoding helpers: `emitExtractRex2Prefix`, `AddRex2WPrefix`, `insKMaskBaseSize` (all declared but never defined); `AddVexPrefixIfNeeded`, `AddVexPrefixIfNeededAndNotPresent`, `AddSimdPrefixIfNeededAndNotPresent` (unused inline defs) - Instruction emitters: `emitIns_AI_R`, `emitIns_I_AI`, `emitIns_I_AX`, `emitIns_R_AX`, `emitIns_AX_R`, `emitIns_I_ARR`, `emitIns_I_ARX`, `emitIns_R_R_AR_I` - Other: `IsAVXOnlyInstruction`, `emitIns_J_S` ---------- Checked for cascaded dead code after removal via a zero-caller scan over all emitxarch.h-declared method names -- no functions became newly dead as a result of these deletions; every helper the removed bodies called remains used elsewhere. `emitIns_IJ` was found to be a pre-existing zero-caller function unrelated to this change, so it is intentionally left out of scope here. Build (`build.cmd clr.jit -c checked -a x64`) succeeds with 0 warnings / 0 errors, and jit-format produces no changes. > [!NOTE] > This PR description and the changes were drafted with the assistance of GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

`Runtime_129288.cs` was added in #129348 (`JIT: don't claim rotates set ZF on xarch`) as a merged-style xunit test (`[Fact] public static int TestEntryPoint()`), but it was never referenced by any `Regression_*.csproj`. Since the SDK-style CLR test projects set `EnableDefaultItems=false`, an unreferenced `.cs` is silently never built or run -- so CI has never exercised this test. This is the same class of bug fixed in #130832. Add it to `Regression_ro_2.csproj` (an `Optimize=True` bucket, correct for this lowering/codegen correctness test), inserted in numeric order alongside its neighbors. I also audited every other `.cs` under `src/tests/JIT/Regression/` for the same issue. The only genuine orphan was `Runtime_129288`. Six other unreferenced `.cs` files are intentionally uncompiled reference sources paired with a hand-written/generated `.il` + `.ilproj` (`Runtime_70259`, `Runtime_70607`, `Runtime_73615`, `Runtime_80731`, `Runtime_40607`, `DevDiv_754566`) and were left as-is. > [!NOTE] > This PR description and the change were generated with the assistance of GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Fixes #128478 I saw there are reported perf regressions for `TensorPrimitives.IndexOfMax` in #128088, so I understand if you can't take this PR to fix that (or revert #127454). PR also includes: - Add coverage for fixed bug in `IndexOf*Magnitude_Negative1LesserThanPositive1` - Tighten asserts and don't avoid `MinValue` in `IndexOf*Magnitude_AllLengths` - Increase coverage in `IndexOf*_Negative0LesserThanPositive0` to cover vectorized paths. - Ensure floating point tests for `TensorPrimtivies` are run for `NFloat`

## Summary Fixes #125794. AOT-published Blazor WebAssembly apps that use `BlazorWebAssemblyLazyLoad` crash during Mono runtime startup — reported as `appdomain.c` assertion (`condition '<disabled>' not met`) and, in other configurations, `interp.c` `NIY … should not be reached`. ## Root cause An AOT image *hard-binds* to every assembly it references when the image is loaded. `load_aot_module` in `src/mono/mono/mini/aot-runtime.c` eagerly calls `load_image` for all referenced images unless the `aot-lazy-assembly-load` runtime option is set: ```c /* … we have to load all referenced assemblies non-lazily … */ if (!mono_opt_aot_lazy_assembly_load) { for (guint32 i = 0; i < amodule->image_table_len; ++i) load_image (amodule, i, load_error); } ``` A `BlazorWebAssemblyLazyLoad` assembly is **not present at runtime startup** (it is downloaded on demand). So when the main app's AOT image is loaded, resolving its lazy dependency fails and the image is marked *"unusable because dependency `<asm>` is not found"*. Every method in that image then falls back to the interpreter, which hits an unsupported construct and aborts: ``` [MONO] AOT: module WasmBasicTestApp is unusable because dependency Json is not found. MONO interpreter: NIY encountered in method <Module>:.cctor () [MONO] * Assertion: should not be reached at .../mono/mini/interp/interp.c:4135 ``` ## Fix Automatically enable the runtime's existing `aot-lazy-assembly-load` option from the WebAssembly SDK when AOT is combined with `BlazorWebAssemblyLazyLoad`. This defers binding of a referenced lazy assembly until it is actually loaded, so the referencing AOT image stays usable. The option flows through `runtimeOptions` in the boot config → `mono_wasm_parse_runtime_options` → `mono_options_parse_options`. The change is scoped to `RunAOTCompilation=true` + at least one `BlazorWebAssemblyLazyLoad` item, so non-AOT and non-lazy builds are unaffected. ## Test `LazyLoadingTests` previously only covered the interpreter (Debug) configuration. Added `LoadLazyAssemblyWithAOT` (`native-mono`, Release + AOT + lazy load) which reproduces the crash without the fix and passes with it. ### Verification Built the browser (Mono + CoreCLR runtime packs) and workload locally and ran the new test. - **Without the fix:** `module WasmBasicTestApp is unusable because dependency Json is not found` → `interp.c:4135` assertion → timed out waiting for `WASM EXIT`. ❌ - **With the fix:** `AOT: image 'WasmBasicTestApp' found.`, `firstJsonLoad=true`, `{"FirstName":"John","LastName":"Doe"}`, `WASM EXIT 0`. ✅ > [!NOTE] > This pull request was authored with GitHub Copilot.

Switches multicast to `Wrapper[]`, cleans up and spanifies combine/remove. Cleans up code after the moves and type changes.

…nstructions (#130339) ## Summary Reworks the repository's customized code-review automation into two complementary parts: 1. A deterministic orchestrator plus a per-PR agentic workflow that replaces the previous `pull_request`-triggered `code-review.md` 2. Path-specific review instructions broken out of the code-review skill so GitHub's built-in Copilot code review agent applies the same dotnet/runtime-specific rules. The dispatched agentic workflow submits a single, cumulative "Holistic Review" per commit range rather than a stateless diff-only pass, and it is designed to run alongside — not replace — the built-in Copilot reviewer. ## Behavior: draft, ready, and closed pull requests - **Ready (non-draft), open PRs** are polled on a 10-minute schedule; the orchestrator dispatches one worker run per PR whenever it is new or its head commit changed since the last durable review. - **Draft PRs are excluded from the scheduled poll.** They can still be reviewed on demand: `holistic-review-orchestrator`'s `workflow_dispatch` accepts a comma-separated `pr_numbers` input ("including drafts and retry-limited review targets") that bypasses the draft filter for exactly the requested PRs, and an unchanged head with an existing durable review is not reviewed again. - **Scheduled runs skip forks while manual runs remain available.** The dispatch job runs for `workflow_dispatch` or when the repository is not a fork, preventing scheduled fork runs without blocking explicit manual dispatch. - Manual and scheduled dispatch share the exact same state, retry, and dedup logic — there is no separate manual code path to keep in sync. ## Coexistence with the built-in Copilot code review agent The Holistic Review worker and GitHub's built-in Copilot code review agent are fully independent; neither waits on, hides, or edits the other's output, and both remain visible on the PR alongside human reviews. The path-specific instruction files under `.github/instructions/` are consumed natively by both: the Holistic Review skill explicitly loads them, and Copilot's built-in reviewer already applies any `.instructions.md` file whose `applyTo` glob matches the changed paths. Every Holistic Review ends with an explicit disclosure distinguishing it from the built-in review and linking back to the `holistic-review.md` workflow source. Reviews are strictly additive: the worker's only two safe outputs are up to 10 inline `create_pull_request_review_comment` calls and exactly one `submit_pull_request_review`, whose event is restricted to `COMMENT`. It never submits `APPROVE` or `REQUEST_CHANGES`, and it never modifies, hides, or supersedes an earlier review or comment from this workflow, the built-in reviewer, or a human. ## Architecture: deterministic orchestrator + gh-aw worker - **`holistic-review-orchestrator.yml`** is a conventional, deterministic GitHub Actions workflow — not an agentic workflow. Its top-level `permissions: {}` grants only `actions: write` / `pull-requests: write` inside its single job, and it does nothing but call the GitHub REST API to decide what to dispatch and to read/write one managed state comment per PR. It never checks out PR content and never runs a model, keeping it secure even though it processes untrusted PR metadata. - **`holistic-review.md`** is the `gh-aw`-compiled agentic worker (compiled to `holistic-review.lock.yml` with gh-aw v0.82.6, pinned via `.github/aw/actions-lock.json` to `github/gh-aw-actions/setup@v0.82.6`). The orchestrator dispatches it once per PR via the Actions API with the PR number, base ref, head SHA, the previously reviewed head and base SHA (when re-reviewing), a bounded review-history JSON blob, and a complete synthetic `aw_context` (`run_id`, `repo`, `workflow_id`, `item_type`, `item_number`) so gh-aw's safe-output layer has full pull-request context even though the triggering event is `workflow_dispatch`, not `pull_request`. - The orchestrator and worker communicate only through `workflow_dispatch` inputs at dispatch time and the worker's own submitted review afterward, which the orchestrator discovers by matching the run's `display_title` (`Holistic Review #<PR> (<head SHA>)`) and by recognizing gh-aw's automatic `` review-footer marker. See `github/gh-aw`'s documentation on compiled agentic workflows, safe outputs, and `workflow_dispatch`-based dispatch, and GitHub's own [`workflow_dispatch`](https://docs.github.com/actions/using-workflows/manually-running-a-workflow) and [triggering-a-workflow](https://docs.github.com/actions/using-workflows/triggering-a-workflow) documentation, for background on the primitives this design builds on. ## Why review state lives in a pull request comment Each PR carries exactly one managed, orchestrator-owned issue comment holding a versioned (`version: 5`) JSON state object: the last dispatched and last reviewed `(commit, base ref, base SHA)` pairs, the ID of the worker run that produced the last recorded review, a bounded initial-plus-latest review-history array, and a bounded `review_attempt_count`. Comments were chosen over gh-aw's repo-memory/cache mechanisms because gh-aw v0.82.6 supports deterministic reads of repo-memory/comment-memory but not deterministic *write-back* of durable state from a dispatch-triggered workflow. A `pull-requests: write`-scoped comment is visible, auditable state that survives reruns, needs no `contents: write`, and is trivially inspectable by anyone reading the PR. Crucially, **a submitted, marker-tagged worker review is the authoritative record of what has actually been reviewed — not the state comment**; the comment only suppresses duplicate in-flight dispatches, and legacy comment formats (including a pre-existing machine-only JSON format and an older HTML-marker format) are recognized once and migrated to the current schema in place. ## Retries and durable-review authority A worker run that completes without submitting a review — a transient provider error, a threat-detection replacement, or a safe-output formatting failure — is never treated as "reviewed." The orchestrator only advances `last_reviewed_*` when it finds a matching, marker-tagged submitted review for the exact dispatched commit and base; otherwise it clears that dispatch record and redispatches the same target. Retries for the same `(head, base)` target are bounded at `MAX_REVIEW_ATTEMPTS = 5`; once exhausted, the PR is reported as retry-limited in the workflow step summary rather than dispatched indefinitely, and it can still be retried explicitly through the manual `pr_numbers` input. Because attempts are keyed by `(head commit, base branch)`, a rebase, force-push, or base retarget resets the attempt counter for the new target instead of inheriting an unrelated failure count. ## Review scope: holistic initial review vs. patch-differential incremental review A trusted, deterministic pre-agent step — not the model — computes the review scope before the agent starts: it resolves the current merge base, computes a patch ID for the PR's cumulative diff, and (for re-reviews) computes the previous merge base, a previous patch ID, a `git range-diff`, and a raw patch diff, writing all of it to `metadata.json` plus `range-diff.txt`/`patch-diff.txt` for the agent to read. - **Initial review:** analyzes the complete `current_merge_base..head` range — the PR's actual base-to-head diff, not its head compared against the current state of the base branch. - **Re-review (incremental):** uses two distinct scopes. It re-reads the complete current base-to-head range only to refresh the cumulative Motivation/Approach/Summary assessment, explicitly comparing against the initial and most recent recorded reviews (retrieved by ID, not rediscovered from the general review list) and stating whether each is unchanged or changed and why. Detailed/actionable findings are restricted to the prepared `range-diff`/`patch-diff` between the previous and current cumulative patches — not a raw tree diff between the two head commits — so a rebase that pulls in unrelated upstream changes cannot manufacture new findings. If the previous and current heads are identical but the merge base changed (a pure base retarget), the same prepared patch comparison is authoritative: only code whose inclusion or semantics changed because of the retarget is reviewed, and unchanged portions of the PR patch are not rediscovered. If the patch truly has not changed, the worker still submits a `COMMENT` review recording that fact and the refreshed Assessment History, so every successful run leaves a durable record. ## Model selection The workflow does not hard-code a model. `engine.model` resolves from the workflow-specific `HOLISTIC_REVIEW_MODEL` Actions variable, allowing the model to be selected at environment, repository, or organization scope without editing or recompiling the workflow. ## Security model - **Least privilege throughout.** The orchestrator's job-scoped permissions are `actions: write` / `pull-requests: write` only; the worker's top-level permissions are `contents: read`, `issues: read`, `pull-requests: read`, and its actual review/comment capability comes from gh-aw's safe-output layer rather than a broadly scoped token held by the agent. - **GitHub reads go through the job-scoped, read-only token.** `tools.github.github-token` is pinned to `${{ secrets.GITHUB_TOKEN }}`, so the agent's `gh`/GitHub-proxy calls cannot be backed by a broader `GH_AW_GITHUB_*` secret, and the declared read-only permissions are actually authoritative. - **PR content — including its own configuration files — is treated as untrusted input.** The worker checks out the dispatched head commit, then removes and restores every agent-configuration path gh-aw v0.82.6 recognizes (the complete `.github` tree, every supported engine configuration directory, and all recognized root instruction files) from `main` before loading any guidance, because a plain checkout alone would leave PR-added files in those paths behind. PR versions of those paths — along with PR descriptions, comments, source comments, test data, and other PR-controlled text — are treated strictly as untrusted review content, never as instructions; changed files under a trusted overlay path are still reviewed from an explicit commit read or the PR diff, never from the restored worktree copy. - **A narrow, read-only shell allowlist with no build/test/execute capability.** The worker cannot run builds or tests, restore or install dependencies, execute PR-provided scripts or binaries, or make direct outbound HTTP requests; there is no `web-fetch` tool. The allowlist further excludes general-purpose process-launch surfaces (`awk`, `find`, `xargs`, `rg`, `sed`, `sort`, `gh`) so an allowlisted command cannot spawn another process or modify the workspace; the prompt separately forbids Git/GitHub CLI aliases, hooks, pagers, external helpers, credential helpers, and other child-process-spawning options, and treats the remaining compiler-injected `git`/`gh`/`sort` surface honestly as defense in depth rather than a strict sandbox. - **Egress is narrowed and routed through a CLI-side proxy.** `network.allowed` is limited to `defaults` (no `dotnet` feed access, since builds/restores are disallowed), and `tools.cli-proxy: true` alongside `tools.github.mode: gh-proxy` ensures no native MCP endpoints remain mounted in the CLI — only the CLI-mounted `safeoutputs` server — avoiding a firewall interaction where native endpoints bypassed the intended proxy path and were denied. - **Both safe outputs are bound to the exact dispatched PR**, not a wildcard or an agent-supplied target: `target: ${{ github.event.inputs.pr_number }}` on both `create-pull-request-review-comment` and `submit-pull-request-review`. A review cannot be redirected to any PR other than the one the orchestrator dispatched. - **Agent checkouts don't carry credentials.** Because gh-aw strips Git credentials before the agent runs, `pre-agent-steps` perform a token-scoped fetch of exactly the commits the review needs (current head, prior head, and prior base) while a token is still available, so the agent operates only on local Git objects afterward, including across force-pushes and retargets. ## Shared review instructions The review rules that used to live entirely in `.github/skills/code-review/SKILL.md` are split into path-scoped `.github/instructions/*.instructions.md` files, each with an `applyTo` glob, so they're consumed identically by the Holistic Review skill and by GitHub's built-in Copilot code review agent: - **`review-all-src.instructions.md`** (`src/**`) — reviewer mindset, the Holistic PR Assessment (motivation, evidence, approach, cost-benefit, scope, risk, codebase fit), PR hygiene, code reuse, established conventions (including preserving pre-existing alphabetical ordering in modified `.csproj` item groups and similar lists, flagging only ordering regressions the PR introduces, not pre-existing unsorted entries), and documentation/comment rules. - **`review-csharp.instructions.md`** (`**/*.cs`) — C#-specific error handling, thread safety, security, correctness, performance/allocation, API design, and style rules. - **`review-native.instructions.md`** (C/C++/asm globs) — JIT-specific correctness, C++ style, VM/interpreter conventions, native size/offset overflow guarding, platform defines, and P/Invoke marshalling. - **`review-all-tests.instructions.md`** (test globs) — testing conventions and regression-test expectations. - **`review-core-runtime.instructions.md`** (`src/coreclr/**,src/native/corehost/**`) — CoreCLR/compiler/host-specific correctness, collectibility, allocation, and PR-prerequisite guidance that should not load for ordinary managed-library changes. The broad C#, native, and test files explicitly state that PR-level gates are preparation guidance during authoring or local experimentation, not reasons to block exploratory work unless review is requested. `SKILL.md` retains the review process and points at these files for substantive guidance. Its area-agent discovery runs only when sub-agent tooling and matching agents actually exist; an instruction file does not imply an agent. The dispatched worker has no such tooling and explicitly skips agent discovery and multi-model fan-out. ## Testing: multi-iteration time-travel replay simulation Because this changes how and when reviews are triggered — not just what they say — it was validated by replaying real PR event timelines (opening commit, subsequent commits, and human review feedback) against the candidate workflow tree in a disposable simulation repository, resetting all simulation PRs and state between rounds and starting the next round only from a clean, freshly deployed tree. --- > [!NOTE] > This PR description was drafted with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

@lindexi

Resolves #117718. Following up on diagnosis by @lindexi. When `NamedPipeClientStream.Connect()` waits for a non-existent pipe on Linux, the internal retry loop creates a `Socket` and calls `Connect()` on every iteration. Each attempt throws and catches a `SocketException`, flooding `FirstChanceException` handlers and wasting CPU on exception allocation. This change adds a `Stat` check at the top of `TryConnect`: if the socket file doesn't exist (`ENOENT`), the method returns `false` immediately without allocating a `Socket` or throwing. Permission errors (`EACCES`) and all other conditions still fall through to the existing `socket.Connect` path, preserving their specific exception behavior. The check introduces a benign TOCTOU window: if the pipe file appears between the `Stat` call and the next loop iteration, `ConnectInternal`'s polling loop picks it up on the subsequent retry. This does not reintroduce the exception flood since the file now exists and `Connect` will either succeed or fail with a non-retryable error. ### Changes - `NamedPipeClientStream.Unix.cs`: Added `Interop.Sys.Stat` / `ENOENT` guard before socket allocation in `TryConnect` - `NamedPipeTest.Specific.cs`: Added Unix-specific test that verifies connecting to a non-existent pipe does not flood `FirstChanceException` with `SocketException`s ### Test plan - New test: `ClientConnect_PipeNotFound_DoesNotFloodFirstChanceExceptions` — connects to a non-existent pipe for 500ms, asserts fewer than 5 `SocketException`s via `FirstChanceException` (previously hundreds/thousands) - Existing test: `ClientConnect_Throws_Timeout_When_Pipe_Not_Found` — verifies `TimeoutException` still thrown (unchanged behavior) --------- Signed-off-by: haltandcatchwater <angeloregalbutophotography@gmail.com>

…tifact (#128498) ## Summary Migrates all remaining `PublishBuildArtifacts@1` / `DownloadBuildArtifacts@0` usage in `eng/pipelines/` to `PublishPipelineArtifact@1` / `DownloadPipelineArtifact@2`. Pipeline Artifacts use dedup-based upload and are 10-100x faster than legacy Build Artifacts. This migration reduces agent time spent on artifact publishing and returns agents to the pool sooner, reducing queue pressure for all pipelines sharing the same pools. ## Artifact naming strategy Pipeline Artifacts cannot be overwritten on retry (unlike Build Artifacts), so artifact names must account for `System.JobAttempt`: - **Diagnostic artifacts** (logs, binlogs, test results): suffixed with `_Attempt$(System.JobAttempt)` to avoid collisions on retry - **Intermediate artifacts** consumed by downstream jobs: use **stable names** (no Attempt suffix) and publish only on `succeeded()` so retries can publish cleanly ## Changes ### Publish wrapper - `eng/pipelines/common/templates/publish-build-artifacts.yml`: `PublishBuildArtifacts@1` / `1ES.PublishBuildArtifacts@1` → `PublishPipelineArtifact@1` / `1ES.PublishPipelineArtifact@1` - `upload-artifact-step.yml`, `upload-intermediate-artifacts-step.yml`: updated input names (`PathtoPublish` → `targetPath`, etc.) ### WASM - `wasm-post-build-steps.yml`: 2 direct calls migrated; stable artifact names preserved for downstream consumption ### Performance templates - `build-perf-sample-apps.yml`: 10 binlog publish steps → `_Attempt$(System.JobAttempt)` suffix (diagnostic) - `build-perf-bdn-app.yml`: 1 binlog → `_Attempt` suffix - `build-perf-maui-apps-net6.yml`, `build-perf-maui-apps-net7.yml`: 6 binlogs each → `_Attempt` suffix ### Downloads - `download-artifact-step.yml`, `download-specific-artifact-step.yml`, `browser-wasm-build-tests.yml`, `browser-wasm-coreclr-build-tests.yml`: migrated to `DownloadPipelineArtifact@2` ## Not changed - `eng/common/` files (managed by Arcade; the `templates/job/job.yml` wrapper already routes `enablePublishBuildArtifacts` through `publish-pipeline-artifacts` with `_Attempt` suffix) - `enablePublishBuildArtifacts: true` parameter references in SuperPMI/libraries templates (parameter name only; already handled by Arcade wrapper) --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

`RtlAddGrowableFunctionTable` and related APIs were introduced in Windows 8.

…mon.h (#130928) Removes redundant/stale preprocessor defines and a block of blanket MSVC warning suppressions from `src/coreclr/vm/common.h`, and cleans up dead `USE_COM_CONTEXT_DEF` / `_CRT_DEPENDENCY_` defines from the debug/md/unwinder `stdafx.h` files. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com>

Tier 1 assertion propagation could incorrectly remove an unsigned addition’s overflow check because JIT ranges use signed intervals. - **Range analysis** - Reject unsigned ranges that straddle signed zero. - Require sums to remain representable by the signed range model. - **Regression coverage** - Cover the reported checked-addition failure and sign-straddling ranges. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: EgorBo <523221+EgorBo@users.noreply.github.com> Co-authored-by: Egor Bogatov <egorbo@gmail.com>

Reduces unsafe code use in `decimal` where it was easy to remove. These changes are all either performance neutral or improvements. For the remaining cases the changes are more involved and need thorough perf measurements and some effort to offset the perf losses. --------- Co-authored-by: Jeff Handley <jeffhandley@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…rator (#131022) ## Summary Fixes #110870. Building a browser-wasm app that references a **Windows-only** P/Invoke with non-blittable parameters (e.g. the gdi32 `GetCharABCWidthsFloat`, which takes `HandleRef` / `object`) emits spurious diagnostics on the **Mono** wasm backend: ``` WASM0060 : Type System.Object is not blittable: Not a ValueType WASM0062 : Type System.Runtime.InteropServices.HandleRef is not blittable: Field _wrapper is not blittable WASM0001 : Could not get pinvoke, or callbacks for method '...GetCharABCWidthsFloat' because 'System.NotSupportedException: Unsupported parameter type ...' ``` ## Root cause The Mono pinvoke collector (`src/tasks/WasmAppBuilder/mono/PInvokeCollector.cs`) analyzed **every** P/Invoke and callback in every referenced assembly, without consulting `[SupportedOSPlatform]` / `[UnsupportedOSPlatform]`. So a method that is only usable on Windows still had its (non-blittable) signature analyzed when targeting the browser, producing the warnings. The **CoreCLR** collector already handles this — it skips a method up front via `IsUnsupportedOnPlatform` / `EvaluatePlatformAttributes`, driven by a `TargetOS`. That check was never ported to the Mono collector, so #110870 still reproduces on Mono while it's fixed on CoreCLR. ## Fix Mirror the CoreCLR platform check into the Mono generator: - Thread `TargetOS` through `ManagedToNativeGenerator` → `PInvokeTableGenerator` → `PInvokeCollector` (the shared `<ManagedToNativeGenerator>` invocation now passes `TargetOS="$(TargetOS)"`; the Mono task gets a `TargetOS` property defaulting to `browser`, mirroring CoreCLR). - Skip pinvokes and callbacks whose method, declaring type (including nesting), or assembly is unsupported on the target OS — i.e. `[UnsupportedOSPlatform(target)]`, or a `[SupportedOSPlatform(...)]` list that doesn't include the target. Only affects the Mono wasm build task; CoreCLR is unchanged. ## Test Adds `PInvokeTableGeneratorTests.UnsupportedOSPlatformPInvokeIsSkipped`: builds a browser app containing a `[SupportedOSPlatform("windows")]` non-blittable pinvoke and asserts none of `WASM0001`/`WASM0060`/`WASM0062` are emitted. ### Verification Built the Mono wasm build task and ran a repro (browser app with a `[SupportedOSPlatform("windows")]` gdi32-style pinvoke taking `HandleRef`/`object`), plus the new WBT test: - **Without the fix:** `WASM0060` + `WASM0062` + `WASM0001` (matching the report). - **With the fix:** 0 warnings; the new test passes (Debug + Release). > [!NOTE] > This pull request was authored with GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…131025) ## Summary Fixes #120327. A `dotnet publish` of a WebAssembly app (native/emcc build) fails on Windows when the user profile name contains parentheses, e.g. `C:\Users\John(US)`: ``` WasmApp.Common.targets: error : Failed to compile ...\runtime.c -> ...\runtime.o 'C:\Users\John' is not recognized as an internal or external command, operable program or batch file. ``` The project path itself is fine — the parentheses are in the **home/temp** path. ## Root cause `Utils.RunShellCommand` (used by the `EmccCompile` task) writes the compiler command to a temporary batch file under `Path.GetTempPath()` and runs it as: ``` cmd /c "<tempdir>\tmpXXXX.cmd" ``` `Path.GetTempPath()` is under the user profile (`C:\Users\John(US)\AppData\Local\Temp\...`), so that quoted path contains `(` and `)`. `cmd`'s `/c` quote-handling rule only preserves the quotes when there are **no** special characters between them; parentheses are special, so `cmd` strips the surrounding quotes and then parses the now-unquoted path up to the first `(` — treating `C:\Users\John` as the command and reporting "is not recognized". The native build then fails. (Everything earlier in the build succeeds, which is why the failure only surfaces at the emcc compile step.) ## Fix Invoke the script with `/S` plus an extra pair of quotes: ``` cmd /S /c ""<tempdir>\tmpXXXX.cmd"" ``` `/S` makes `cmd` strip only the outermost pair of quotes and treat the remainder verbatim, so the inner quotes around the path are preserved and the path is passed intact regardless of parentheses/spaces. The Unix `/bin/sh` path is unaffected (the quoted path is passed as a single argv and never re-parsed) and is left unchanged. ## Test Adds `NativeBuildTests.NativeBuildWithParenthesesInTempPath`: a native (`WasmBuildNative=true`) build with `%TMP%`/`%TEMP%` pointed at a directory containing parentheses. It's gated to Windows (`[SkipOnPlatform(TestPlatforms.AnyUnix, …)]`) because the `cmd.exe` quote-stripping behavior is Windows-specific. ### Verification - The failure only reproduces on Windows `cmd.exe`; the Unix `/bin/sh` code path is not affected, so it cannot be reproduced on Linux/macOS. - Locally (macOS): confirmed the `WasmAppBuilder` task and the `Wasm.Build.Tests` project both compile cleanly with the change. - The regression test exercises the real end-to-end native build with a parenthesized temp path on Windows CI, where it fails without this fix. > [!NOTE] > This pull request was authored with GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

## Summary Fixes #112262. A P/Invoke whose argument is an enum with a **64-bit underlying type** (e.g. `[Flags] enum Flags : ulong`) crashes on wasm at the call site with `RuntimeError: null function or function signature mismatch`. ## Root cause `interp_type_as_ptr()` (interp/transform.c) decides whether a native call can take the fast `MINT_CALLI_NAT_FAST` → `do_icall` path, which passes every argument as a pointer-sized `gpointer`. It treated **every enum as pointer-compatible without checking its underlying type**: ```c if (tp->type == MONO_TYPE_VALUETYPE && m_class_is_enumtype (...)) return TRUE; // ignores underlying type ``` Raw `long`/`ulong` are already correctly excluded on 32-bit targets via the `#if SIZEOF_VOID_P == 8` guard (which is why the documented workaround — casting the enum to `ulong` — works), but a 64-bit **enum** slipped through. `do_icall` then called the native `void(int64_t)` as `void(int32_t)` on wasm32 → `call_indirect` signature mismatch. ## Fix Only a 64-bit enum can be misclassified as pointer-sized on a 32-bit target, so for enums with an `I8`/`U8` underlying type defer to the underlying type (which is `SIZEOF_VOID_P`-guarded); all other enums keep their existing classification. Behavior only changes for enums with a 64-bit underlying type on 32-bit targets such as wasm32; `enum:int`/`enum:uint`/smaller enums and all enums on 64-bit hosts are unchanged. `interp_type_as_ptr` is interp-transform-only; the AOT (`type_to_c`) and jiterpreter (`mono_type_to_ldind`) signature paths already reduce enums to their underlying type, so no parallel change is needed. ## Test Extended the existing WASM ABI pinvoke test (`AbiRules.cs` + `wasm-abi.c`) with `enum:ulong` and `enum:long` direct pinvokes — the two cases the fix changes. `EnsureWasmAbiRulesAreFollowedInInterpreter` (the interpreter path where the bug lives) exercises the regression. ### Verification Built the browser Mono runtime with the fix and ran the WASM ABI interpreter test end-to-end: - **Without the fix:** `void(enum:ulong)` pinvoke → `function signature mismatch`, app aborts before running. - **With the fix:** test passes; native round-trips the full 64-bit value (`eu (eu)=18374966859414961921`, `ei (ei)=-2`). Also verified out-of-band that a pinvoke argument of every enum width — `byte`/`sbyte`/`short`/`ushort`/`int`/`uint`/`long`/`ulong` — round-trips correctly on wasm with this change. > [!NOTE] > This pull request was authored with GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Two latent correctness fixes found while auditing `gentree.cpp`, each with a regression test. ---------- **Fix `GetOperForHWIntrinsicId` testing the `isScalar` pointer instead of `*isScalar`** (#130830) `GetOperForHWIntrinsicId` refines a `GT_SUB` into a `GT_NEG` when the constant `op1` is a scalar zero, but it guarded on the `isScalar` out-param pointer (always non-null) rather than the dereferenced value. This let a **packed** subtract whose constant has a zero low lane but is not all-zero (e.g. `Vector128.Create(0, 1, 2, 3) - x`) be reported as a negate. `fgOptimizeHWIntrinsic`'s `(-v1) + v2 => v2 - v1` transform then drops the constant entirely. ---------- **Fix stray block clobbering `needsFixup` in `gtNewSimdMinMaxNode`** (#130831) A stray unconditional block in the min branch of the floating constant fast path overwrote `needsFixup` for all four cases, making the preceding if/else dead. `needsFixup` signals that a signed-zero constant needs the AVX512 fixup so `min(+0, -0)` keeps the correct sign of zero; with it wrongly forced `false`, `Min`/`MinNumber` against a signed-zero constant miscompiles. The min branch now mirrors the already-correct max branch. Existing coverage in `JitBlue/Runtime_98068` exercises `Min`/`MinNumber` const-folding but always pairs an operand with `NaN`, so the finite opposite-signed-zero case was never tested. ---------- Both are pre-existing on `main`, found by inspection. Tests added under `JitBlue/Runtime_130830` and `JitBlue/Runtime_130831`. CC. @dotnet/jit-contrib > [!NOTE] > This PR description was authored with the help of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…rget methods (#130630) fixes #130364 --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>

## Summary Converts the cDAC `TypeHandle` value type into an `ITypeHandle` interface with a canonical, target-backed implementation (`TargetTypeHandle`). This is a foundational refactor; **synthetic (reader-fabricated) type handles for unloaded constructed types are deferred to a follow-up PR.** Absent or unresolved types use standard C# nullable-reference semantics (`ITypeHandle?` / `null`). Non-null handles are canonical identities produced and interned by `RuntimeTypeSystem` within a target cache epoch. ## Motivation This change is primarily **enabling groundwork**. Turning `TypeHandle` into an interface lets the Runtime Type System (RTS) contract grow in two directions that the current value-type shape cannot accommodate: - **Versioning** -- different contract versions can supply their own `ITypeHandle` implementations without changing every consumer when the representation evolves. - **More expansive RTS support** -- most immediately, synthetic handles for constructed types (`Ptr`/`Byref`/`SzArray`/`Array`, and later generic instantiations) that are not loaded in the target. A polymorphic `ITypeHandle` lets RTS fabricate a queryable handle instead of relying on ad-hoc side channels. ## Behavior note The old struct compared by address value. The new handles use canonical reference identity: repeated `GetTypeHandle` calls for the same address return the same object until `Target.Flush` invalidates the cache. Resolving the same address after a flush may return a different object reference. This identity change is intentional and prevents future handle implementations from having to coordinate cross-implementation value equality. ## Changes - Rename `TypeHandle` -> `ITypeHandle` across cDAC type references (members named `TypeHandle` remain unchanged). - Add the `ITypeHandle` interface in Abstractions (`Address`). - Add the internal `TargetTypeHandle` implementation for real target-backed handles. - Intern target handles per address so repeated `GetTypeHandle` calls return the same canonical instance within a cache epoch. - Use reference identity for constructed-type cache keys. - Represent absent/unresolved handles with nullable references and annotate the affected contracts and consumers. - Preserve the existing `ReadOnlySpan` collection API shapes. - Update the authoritative data-contract documentation. ## Why split it this way The original draft also added synthetic handles and reworked calling-convention side channels in one change. Splitting out the interface conversion keeps this PR focused; synthetic-handle behavior and its downstream simplifications can build on the stable `ITypeHandle` abstraction in a follow-up. ## Testing - Contracts and Legacy build cleanly. - All **2733** cDAC unit tests pass (16 skipped). - All **34** DataGenerator tests pass. - DumpTests and StressTests compile. > [!NOTE] > This PR description and the changes were produced with the assistance of GitHub Copilot. --------- Co-authored-by: Max Charlamb <maxcharlamb@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>

The r2r.yml was deleted, but the corresponding AzDO pipeline definition wasn't deleted, and this is causing warnings on AzDO. I don't have permission to delete the definition, so we can add a dummy file in the meantime to avoid those warnings. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

On WASM, `GetThreadStaticsBase()` computes the `ThreadLocalData*` by taking the address of `DirectOnThreadLocalData.pNativeThread`. On WASM, that field access goes through `StaticsHelpers.GetNonGCThreadStaticBase`, which itself calls `GetThreadStaticsBase()` — infinite recursion. Fix: add a `GetThreadStaticsBaseNative` FCall (WASM-only) that returns `&t_ThreadStatics` directly from native, bypassing the managed thread-static lookup path. - **`Thread.CoreCLR.cs`**: `#if TARGET_WASM` path in `GetThreadStaticsBase()` calls `GetThreadStaticsBaseNative()` instead of the `&pNativeThread` pointer arithmetic; declares the FCall as `[MethodImpl(InternalCall)]`. - **`comsynchronizable.h`**: declares `GetThreadStaticsBaseNative` FCDECL (WASM-only). - **`comsynchronizable.cpp`**: implements it returning `(void*)&t_ThreadStatics`; adds `#include "threadstatics.h"`. - **`ecalllist.h`**: registers the FCall (WASM-only). Extracted from main...AndyAyersMS:runtime:next-blocker-spc. Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: davidwrighton <10779849+davidwrighton@users.noreply.github.com>

- They should always be READYTORUN_FIXUP_PInvokeTarget instead of READYTORUN_FIXUP_IndirectPInvokeTarget - There is a debug version of JIT_PinvokeEnd which validates that sp == the __stack_pointer global. I believe our codegen will maintain this invariant, so we should be ok to skip resetting the __stack_pointer global before calls to the C++ implementation of JIT_PInvokeEnd - One detail which is no longer true after this work is merged is that the __stack_pointer global will be set to increasingly unpredictable values during execution. This is not a new phenomena, as it was happening during EH flow, but now it will happen in normal execution flow. Since the interpreter to R2R thunks will reset the stack before we return to any emscripten compiled code, we should be ok with this. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…llback from next-blocker-spc (#131121) Extracts the requested subset from `main...AndyAyersMS:runtime:next-blocker-spc`: the `GetCookieForCalliSig` string-constructor handling and the `prestub.cpp` managed-FCall helper entrypoint fix. This narrows the PR to the two runtime paths needed to unblock wasm mixed interpreter/R2R dispatch. - **`src/coreclr/vm/wasm/helpers.cpp` — `GetCookieForCalliSig`** - Adds a string-constructor special case so interpreter→R2R calli cookies use the constructor factory thunk shape (matching existing R2R→interpreter string-ctor handling). - Uses explicit thunk-key mapping by constructor arity, including `ReadOnlySpan<char>` constructor handling. - **`src/coreclr/vm/prestub.cpp` — managed FCall helper publication** - Handles both managed-helper forms under portable entrypoints: - interpreter bytecode available → publish interpreter data; - interpreter bytecode absent (native R2R helper) → publish helper native actual code. - Prevents routing back into prestub when the helper resolves to native code. ```cpp if (ilStubInterpData != NULL) { SetInterpreterCode((InterpByteCodeStart*)ilStubInterpData); PortableEntryPoint::SetInterpreterData(entryPoint, (PCODE)(TADDR)ilStubInterpData); } else { _ASSERTE(PortableEntryPoint::HasNativeEntryPoint(pCode)); PortableEntryPoint::SetActualCode(entryPoint, (PCODE)(TADDR)PortableEntryPoint::GetActualCode(pCode)); } ``` --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: davidwrighton <10779849+davidwrighton@users.noreply.github.com>

Follow-up to #130837. Several `JITDUMP` calls pass a trailing argument to a format string that has no corresponding `%` specifier, so the argument is silently ignored. This removes those leftover args. All are `DEBUG`-only and behavior is unchanged. - `lower.cpp` -- `JITDUMP("Argument is a local\n", numRegs, stackSeg.Size)` (the one called out in #130837) - `importercalls.cpp` -- `arrayElemSize` - `importervectorization.cpp` -- `str` - `inductionvariableopts.cpp` -- `dspTreeID(...)` (redundant; the following `DISPTREE` already dumps the tree) and `lclNum` - `optimizer.cpp` -- `lclNum` - `rangecheck.cpp` -- `expr` (two sites) Found by scanning every `.cpp` under `src/coreclr/jit` for literal format strings with no conversion but a trailing argument; these were the only hits. > [!NOTE] > This PR description and the changes were drafted with GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Fixes #131137. PR #130444 started removing transparent scalar/vector reinterpret `HWINTRINSIC` nodes (`CreateScalarUnsafe`, `GetLower`/`GetLower128`, `ToVector256Unsafe`/`ToVector512Unsafe`) during lowering when the consumer is another `HWINTRINSIC`. That's correct in general -- the consumer reads the value from a register at its own size -- but two x64 codegen sites keyed their decision off the *operand's* post-lowering type, which the elision changes. Both now produce wrong code. ---------- **`ConvertToVector128Int*` / `ConvertToVector256Int*` (the reported crash)** These have a vector overload `(Vector128<T>)` and a pointer overload `(T*)`, both lowering to `pmovzx*`. Codegen picked between them with `varTypeIsSIMD(op1)`. Once an elided `CreateScalarUnsafe` leaves the vector overload's operand scalar-typed, that proxy misfires and codegen takes the memory-load path -- reading the scalar value as if it were an address (the reported `NullReferenceException`; a checked JIT asserts in `emitxarch.cpp`). Fixed by selecting the overload from the stable `node->OperIsMemoryLoad()` metadata (aux-type driven), matching the generic table path already used elsewhere in the file. ---------- **AVX2 gather VSIB index width** A gather selects its VSIB index width (xmm vs ymm) from the index operand's *own* width (`indexOp->TypeIs(TYP_SIMD32)`). An elided `GetLower`/`ToVector*Unsafe` on the index changes that width, so the wrong VEX.L is encoded and the hardware reads the wrong number of indices (e.g. a `vpgatherqd` with a `GetLower()`-narrowed index gathered 4 elements instead of 2 -- a silent wrong result, not visible in the JIT disasm since it always prints the index as `xmm`). The index width can't be recovered in codegen, so this is fixed in lowering: the reinterpret elision is skipped when the node is a gather's index operand, since that width is load-bearing. ---------- I also audited the rest of `hwintrinsiccodegenxarch.cpp`, the store-containment paths in `codegenxarch.cpp`, and `emitxarch.cpp`: every other size/attr decision derives from node metadata (`node->TypeGet()`, `GetSimdSize()`, `GetSimdBaseType()`), and the `operandSize >= expectedSize` check in `IsContainableHWIntrinsicOp` prevents a narrowed operand from being contained undersized. These two sites were the only operand-width-driven exceptions. Added `Runtime_131137` covering both fixed paths (Sse41/Avx2 convert-from-scalar and the gather-with-narrowed-index case); it fails without the fix and passes with it. > [!NOTE] > This PR was authored with the assistance of GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

## Summary - Enable ReadyToRun coverage for `System.Runtime.Loader.DefaultContext.Tests`, `System.Reflection.Tests`, `System.Reflection.TypeExtensions.Tests`, and `System.Runtime.Loader.Tests`. - Account for the ReadyToRun test runner being the entry assembly in Reflection tests. - Load the TypeExtensions fixture explicitly from the published test directory. - Remove bind-failure fixtures from the ReadyToRun publish directory before Helix archives it, while retaining their `deps.json` entries. - Keep `System.Text.RegularExpressions.Tests` excluded for follow-up work. Part of #95928.

) The `parse_only_production` parameter on `c_fx_ver_parse` / `fx_ver_t::parse` was never passed as `true` — every caller used `false` or the default of `false`. Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: elinor-fung <47805090+elinor-fung@users.noreply.github.com>

…ortable entry point compatibility (#131119) Extracts the `InitHelpers.cs` changes from [AndyAyersMS:runtime:next-blocker-spc](main...AndyAyersMS:runtime:next-blocker-spc). On WASM targets using portable entry points, `call_indirect` signatures must match the compiled method exactly including return arity — but the JIT already models these helpers as value-returning (result pushed then discarded). Fix: return a dummy `null` from both helpers. - `InitClass`: `void` → `void*`, invert condition (remove early return), add `return null` - `InitInstantiatedClass`: same treatment - Add comments explaining the WASM `call_indirect` ABI requirement Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: davidwrighton <10779849+davidwrighton@users.noreply.github.com>

`Delegate.Method` needs to work since it's not a trim-unsafe API. I thought I maybe broke this in #129609, but the added test doesn't work in .NET 10 either, so I only broke a small aspect of this (GVMs were implicitly considered targets of reflection because of the `RuntimeMethodHandle` used as implementation detail).

Today several wasm codegen paths bail to the interpreter (`NYI_WASM_SIMD`) because a 128-bit SIMD value arrives as an `i32` (a by-ref pointer) rather than a real `v128` on the wasm value stack. Emitting a `v128.*` op against an `i32` operand produces an invalid module, so the JIT defensively bails. This is the end-to-end blocker for SIMD actually executing on wasm. This change treats `Vector128<T>` as the wasm `v128` ABI primitive and materializes it by value: - `getWasmLowering` maps `Vector128<T>` to `CORINFO_WASM_TYPE_V128`, and `ToJitType` maps that to `TYP_SIMD16`. - The five codegen sites that previously bailed now emit real `v128` values: SIMD parameter homing, SIMD16 local field load, store-indirect, call argument, and local load. - `RaiseSignature` can round-trip the `'V'` signature char back to a concrete v128 type. ---------- **Why only `Vector128<T>`.** It is the single SIMD type the JIT recognizes as `TYP_SIMD16` on wasm. In `getBaseTypeAndSizeOfSIMDType`, `Vector128<T>` (16 bytes) is not target-gated, `where-as` `Vector64<T>` is `TARGET_ARM64`-only and `Vector256<T>`/`Vector512<T>` are `TARGET_XARCH`-only, so on wasm those fall through to `TYP_UNDEF` and are handled as regular structs. The `System.Numerics` vectors (`Vector2`/`Vector3`/`Vector4`, `Vector<T>`, `Plane`, `Quaternion`) are multi-field, so `getWasmLowering` classifies them as passed by reference (they arrive as `TYP_BYREF`, not `varTypeIsSIMD`). The net effect is that the only by-value SIMD value reaching these codegen paths is a `Vector128<T>` in a real `v128` register, so the previous bails are no longer needed and no new gate is required. The other SIMD types keep their pre-change ABI and are deferred to follow-ups. Because every `'V'` in a lowered signature is now exactly 16 bytes, there is no mixed-width offset ambiguity in the signature round-trip. ---------- **Testing.** Adds an R2R test (`WasmSimdModule`) exercising the v128 calling convention — parameter, return, through-local, store-indirect, and call-argument — using `Vector128<int>` without any SIMD arithmetic intrinsics, so only the ABI/materialization paths are covered. Locally, `ILCompiler.ReadyToRun.Tests` (filter `Wasm`) passes 2/2; wasm SIMD only executes in CI, which is the point of this draft. Opening as **draft** for full CI validation. > [!NOTE] > This PR description was drafted with GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Larry Ewing <lewing@gmail.com>

windbg needs an implementation of function table lookup to migrate away from DAC. In DAC this comes from the exported function OutOfProcessFunctionTableCallbackEx but since I didn't want tie the behavior to a specific dll export I created a new interface for it instead. This just creates the stub of an implementation which will still need to be filled in.

…131150) main PR N/A # Description `Delegate.IsDynamicDelegate()` in NativeAOT checked an impossible condition (`GetThunk(MulticastThunk) == IntPtr.Zero`), leaving an unreachable `DynamicInvokeImpl` branch. This change removes that dead representation check and keeps `DynamicInvoke` on the normal reflection-based invoke path. - **Core runtime cleanup** - Deleted `IsDynamicDelegate()`. - Removed unreachable dynamic-delegate branch from `DynamicInvokeImpl`. - Removed obsolete `CombineImpl` guard that depended on `IsDynamicDelegate()`. - **Behavior-preserving simplification** - Retained `ReflectionAugments.GetDelegateDynamicInvokeInfo(GetType())`. - Retained invoke-time exception wrapping (`wrapInTargetInvocationException: true`). - Retained debugger-step annotation behavior. - **Scope control** - Reviewed NativeAOT/runtime/compiler/libraries/tests for code solely tied to this obsolete path. - Removed only code directly coupled to that path; no unrelated thunk machinery changes. ```csharp [DebuggerGuidedStepThroughAttribute] protected virtual object? DynamicInvokeImpl(object?[]? args) { DynamicInvokeInfo dynamicInvokeInfo = ReflectionAugments.GetDelegateDynamicInvokeInfo(GetType()); object? result = dynamicInvokeInfo.Invoke(_target, _methodPtr, args, binderBundle: null, wrapInTargetInvocationException: true); DebugAnnotations.PreviousCallContainsDebuggerStepInCode(); return result; } ``` # Customer Impact Lower maintenance risk in delegate invocation code by removing unreachable logic and redundant branching in a core runtime type. # Regression Not a recent regression fix; this is dead-code removal and path simplification. # Testing Focused validation was run to ensure normal `DynamicInvoke` behavior remains intact (including targeted delegate `DynamicInvoke` coverage) and CoreLib/NativeAOT build viability was rechecked. # Risk Low. Narrowly scoped to deleting unreachable logic and preserving the existing active invocation path. # Package authoring no longer needed in .NET 9 IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version. Keep in mind that we still need package authoring in .NET 8 and older versions. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: MichalStrehovsky <13110571+MichalStrehovsky@users.noreply.github.com>

@EgorBo

Follow up to #131155 (comment). `Runtime_131137` was added with a standalone `.csproj` and `RequiresProcessIsolation=true`, but the test meets none of the isolation rules in [`requiresprocessisolation.md`](https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/coreclr/requiresprocessisolation.md) -- it sets no environment variables, no host config, and no process-wide state. It''s just a `[ConditionalFact]` in a `Runtime_131137` namespace with no custom `Main`, so it merges cleanly. This removes the standalone project and adds the source into the shared `Regression_ro_2.csproj` runner, matching the rest of the regression tests. ---------- I also audited the other recently-added `JitBlue` tests that still carry standalone csprojs. All of them are justified: the immediate neighbors `Runtime_130844`/`130845`/`130846` set `CLRTestEnvironmentVariable`, the remaining ISO ones set `CLRTestEnvironmentVariable`/`CLRTestTargetUnsupported`, and `Runtime_8980` disables the xunit wrapper generator. `Runtime_131137` was the only one with no trigger. CC. @EgorBo > [!NOTE] > This PR description was drafted by Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Test added in #130777. For code like the one below, where the `GetResult` of the value task source throws, the correct stacktrace should point to the await as the source of the throw. However, on interpreter, it is pointing to the new instruction. ``` public static async Task ThrowsSoonValueTaskSource() { ValueTask vt = new ValueTask(new ThrowsSoonValueTaskSourceImpl(), 0); await vt; } ``` The cause of this seems to be that we only report IL->native offsets for locations where the IL stack is empty, therefore we don't have a location at the await. This seems to be easily fixable via BrzVlad@460eae9. The problem with the fix is that it is a partial revert of #127469 so it has a good chance to lead to regressions on other diagnostic tests.

…ith gh-aw v0.82.6 (#131156) Agentic workflows that use the shared `pat_pool` job show a false-positive **"agentic threat detected / results could not be parsed"** banner (e.g. #131122) — the threat-detection job simply can't authenticate. **Cause:** under gh-aw **v0.81.6**, the generated `detection` job's `needs:` is hardcoded to `[activation, agent]` and omits the custom `pat_pool` job. So `needs.pat_pool.outputs.pat_number` is empty, `COPILOT_GITHUB_TOKEN` falls back to `'NO COPILOT PAT AVAILABLE'`, inference returns 503, and no `THREAT_DETECTION_RESULT` is emitted. Fixed upstream in **v0.82.6** (github/gh-aw#44202); `holistic-review` already runs v0.82.6 without the bug. **Fix:** recompiled the 5 affected workflows with gh-aw v0.82.6. Each `detection` job now depends on `pat_pool`: ```diff detection: needs: - activation - agent + - pat_pool ``` The `.md` `COPILOT_GITHUB_TOKEN` is flattened to a single line because v0.82.6's new `Check for OAuth tokens` step emits invalid YAML from a multiline value (same as `holistic-review.md`). --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Implement a check that throws a `PlatformNotSupportedException` when Extended Protection is enforced on platforms that do not support it. Add a corresponding error message for clarity. Include a test to verify this behavior on non-Windows platforms.

This pull request updates the following dependencies [marker]: <> (Begin:0c5a34f5-504e-413b-9376-08d8d8ff2d75) ## From https://github.com/dotnet/runtime-assets - **Subscription**: [0c5a34f5-504e-413b-9376-08d8d8ff2d75](https://maestro.dot.net/subscriptions?search=0c5a34f5-504e-413b-9376-08d8d8ff2d75) - **Build**: [20260630.1](https://dev.azure.com/dnceng/internal/_build/results?buildId=3011545) ([320869](https://maestro.dot.net/channel/8297/github:dotnet:runtime-assets/build/320869)) - **Date Produced**: June 30, 2026 10:44:48 AM UTC - **Commit**: [856cf037e3c32a4ccc485cda2dd7ef36b0bc1882](dotnet/runtime-assets@856cf03) - **Branch**: [main](https://github.com/dotnet/runtime-assets/tree/main) [DependencyUpdate]: <> (Begin) - **Dependency Updates**: - From [11.0.0-beta.26309.3 to 11.0.0-beta.26330.1][1] - Microsoft.DotNet.CilStrip.Sources - Microsoft.DotnetFuzzing.TestData - 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 [1]: dotnet/runtime-assets@741cd9b...856cf03 [DependencyUpdate]: <> (End) [marker]: <> (End:0c5a34f5-504e-413b-9376-08d8d8ff2d75) Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

## Automated Dependency Update This PR contains the following updates: | Package | Update | Change | |---|---|---| | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `8143d3f` → `65b656c` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `57861fa` → `0f6feb7` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `73db6e4` → `0be8725` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `675c5f2` → `428be03` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `cc1824e` → `ad046c7` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `343ffd7` → `f6b4797` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `056735e` → `1608f79` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `ad7d2c3` → `fc02e7d` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `68358db` → `b465025` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `4096bbf` → `76e7e4f` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `71e1591` → `d2582b6` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `620c418` → `f33fe0c` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `cb5214c` → `c0651a1` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `98071fd` → `2407884` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `69d2667` → `8491f14` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `8fdb1a4` → `eaece21` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `b448e8d` → `15dd63b` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `541bfc7` → `5782ea4` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `a9b4b8a` → `f4e3341` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `e309f18` → `db1a34b` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `4961733` → `301907b` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `368e164` → `a52c0bd` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `0afc4da` → `3af9ca1` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `74c557a` → `22acc70` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `594c1a8` → `718da2e` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `7f57a7e` → `f141d28` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `8102bd7` → `e64f6c2` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `4c305ca` → `73ca175` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `fd506e2` → `18ea7a1` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `d89b70a` → `bfa2dd9` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `6104a66` → `5cca2ad` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `b10bded` → `133fdc3` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `d6d5523` → `9fe9680` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `55cafde` → `4eeeb11` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `f2a0932` → `ca817af` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `ec917e9` → `06a5561` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `804a557` → `30b0629` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `042c87f` → `f983894` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `a42042a` → `b903935` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `53845f6` → `2f681f6` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `7fea07e` → `e605ffd` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `e573b57` → `3a37282` | | mcr.microsoft.com/dotnet-buildtools/prereqs | digest | `34918b5` → `91f43da` | This PR has been created automatically by the [.NET Renovate Bot](https://redirect.github.com/dotnet/arcade/blob/main/Documentation/Renovate.md) to update one or more dependencies in your repo. Please review the changes and merge the PR if everything looks good.

…sts (#116166) Co-authored-by: Jeremy Koritzinsky <jekoritz@microsoft.com> Co-authored-by: Jeremy Koritzinsky <jkoritzinsky@gmail.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Move GenerateWasmBootJson test coverage from the temporary tasks.tests project into Wasm.Build.Tests, remove the obsolete tasks.tests csproj, and tag the moved tests as no-workload. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2db6a9dd-0c66-4a48-b2f6-36c7329a5e0e

azure-pipelines · 2026-07-22T10:10:34Z

Azure Pipelines: Successfully started running 2 pipeline(s). 14 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Youssef1313 and others added 30 commits July 22, 2026 11:47

Produce deprecated property in JsonSchema for obsolete types (#130665)

68e9da5

Spec: https://json-schema.org/draft/2020-12/draft-bhutton-json-schema-validation-01#section-9.3

Cleanup multicast delegate handling (#130905)

6675dac

Switches multicast to `Wrapper[]`, cleans up and spanifies combine/remove. Cleans up code after the moves and type changes.

Link statically to GrowableFunctionTable (#131017)

2a00ddd

`RtlAddGrowableFunctionTable` and related APIs were introduced in Windows 8.

[wasm] Html Encode incoming parameters to debug page (#130960)

fb2a1ee

tannergooding and others added 25 commits July 22, 2026 11:48

Change IList<string> to IEnumerable<string> in Process Run/StartAndFo…

8cede7e

…rget methods (#130630) fixes #130364 --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>

dotnet-policy-service Bot added the linkable-framework Issues associated with delivering a linker friendly framework label Jul 22, 2026

dotnet-policy-service Bot assigned maraf Jul 22, 2026

maraf closed this Jul 22, 2026

build-analysis Bot mentioned this pull request Jul 22, 2026

XHarness package install failure on iOS due to devicectl NSPOSIXErrorDomain error 49 #123796

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[browser] Move boot config tests to Wasm.Build.Tests#131199

[browser] Move boot config tests to Wasm.Build.Tests#131199
maraf wants to merge 125 commits into
copilot/update-bootjsondata-generationfrom
maraf/BrowserMoveBootConfigTests-followup

maraf commented Jul 22, 2026

Uh oh!

azure-pipelines Bot commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

Uh oh!

Conversation

maraf commented Jul 22, 2026

Uh oh!

azure-pipelines Bot commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants