`useMemoCache(size)` allocates a fixed array buffer for compiled memoization slots. When called with an invalid `size` argument (e.g. negative numbers or non-integers), V8 throws an unhandled `RangeError: Invalid array length` deep inside reconciler execution.

Following React's developer experience principles, this PR adds a `__DEV__` guard in  `packages/react/src/ReactHooks.js` to log an informative `console.error` warning when `size` is not a non-negative integer, making invalid invocations easy to diagnose during development.

## How did you test this change?

- Ran `yarn test packages/react-reconciler/src/__tests__/useMemoCache-test.js`.
- Verified that passing negative sizes or invalid types in development triggers the `console.error` warning.
- Verified that the check is completely eliminated by Rollup in production builds (`yarn build`).

CLA Signed

React: Add DEV guard validation for useMemoCache size argument

`packages/react/src/ReactCompilerRuntime.js` exports the React Compiler memoization runtime hook (`c`).

This PR adds an explicit Flow type annotation `export const c: (size: number) => Array<mixed> = useMemoCache;` to ensure explicit function signature inference for downstream modules importing `react/compiler-runtime` across monorepo build targets.

## How did you test this change?

- Ran `yarn flow dom-node` to verify Flow type checking succeeds.
- Verified that existing compiler tests (`useMemoCache-test.js` and `compiler-integration-test.js`) continue to pass cleanly.

React: Add explicit Flow type annotation to ReactCompilerRuntime export

 In PR #37187 ("Remove the dead Timeline profiler code"), `packages/react-devtools-timeline` was deleted along
  with its backend profiling hooks. The commit notes explicitly highlighted three follow-up comments left behind:

> *"Three stale comments still name the removed package: `scripts/rollup/wrappers.js:532` and `ReactFiberLane.
  js:38,125`. Left alone to keep this stack purely DevTools-side."*

This PR removes these stale comments from ReactFiberLane.js and updates the reference in wrappers.js to maintain accurate documentation.

## How did you test this change?

 - Ran `yarn linc` to confirm no linting errors on modified files.
 - Confirmed zero functional or runtime logic changes to lane constants or rollup wrappers.

DevTools: Remove stale comments referencing removed timeline package

## Summary

Fixes #37240.

When Flight outlines a static child into its own row, the client wraps the reference in a lazy node (`createLazyChunkWrapper` in the `'L'` case of `parseModelString`). The JSX runtime marks that lazy node as a validated static child in `validateChildKeys`, but `warnOnInvalidKey` resolves the lazy and checks the inner element, which was created when the outlined row initialized and never received the mark. The result is a false `Each child in a list should have a unique "key" prop.` warning for a child that is not in an array — it appears or disappears depending on whether a preceding prop pushes the element past the outlining threshold.

#34350 fixed the same class of warning for blocked elements by transferring the `validated` flag from the lazy wrapper in `initializeElement`, but that path creates the lazy at the element's creation site, so the transfer cannot cover outlined rows, where the wrapper is created at the reference site and the element when the target chunk initializes.

This transfers the wrapper's `validated` flag to the resolved element when `warnOnInvalidKey` unwraps the lazy, mirroring what `validateChildKeys` already does for fulfilled lazy payloads.

## How did you test this change?

- Added a test mirroring the issue: a large preceding prop forces the static child to be outlined. It fails on `main` with the false key warning and passes with this change.
- `yarn test ReactFlightDOMBrowser` (50 tests) and `yarn test ReactFlightDOMBrowser --prod` (50 tests) — pass.
- `yarn test ReactFlight` — 358 pass; the one failure (`ReactFlightAsyncDebugInfo › can track async file reads`) also fails on a clean checkout of `main` in this environment, so it is unrelated.
- `yarn test ReactChildren ReactLazy ReactFragment ReactElement` (149 tests) and `yarn test ReactIncremental ReactCoroutine ReactMultiChild` (180 tests) — pass.
- `yarn prettier`, `yarn linc`, `yarn flow dom-node` — clean.

[Fiber] Fix missing key warning for outlined Flight elements

React version:

## Steps To Reproduce

1.
2.



Link to code example:



## The current behavior


## The expected behavior

A potential issue that we haven't yet confirmed as a bug

Status: Unconfirmed

Bug:

Fix index increment for element removal in operations.

## Summary


 I was facing issue debugging few websites using react-dev-tools-it will help reducing the error occurrence





   I pushed the node value to be picked from the next index before the conditional check so the probability of undefined get reduced since node_ trace having multiple value on further indexes which will track & fix the issue occurrence


[DevTools Bug] Cannot remove node "5060" because no matching node was found in the Store.  #37243

### Website or app

https://www.nike.com/men

### Repro steps



Go to url:-
https://www.nike.com/men or any route
open dev tools , components in react developer tools

I understand this might the compatibility with the react build version but , if we can't change the build version & react dev tool version 7.0.1 (10/20/2025) any alternate resolution, sometimes it is working fine and no newer version available... 



<img width="1913" height="385" alt="Image" src="https://github.com/user-attachments/assets/a7a3396f-22e1-4533-8032-51ae9aae8b87" />





### How often does this bug happen?

Sometimes

### DevTools package (automated)

react-devtools-extensions

### DevTools version (automated)

7.0.1-3cde211b0c

### Error message (automated)

Cannot remove node "5060" because no matching node was found in the Store.

### Error call stack (automated)

```text
at chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:1:726672
    at p.emit (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:1:680330)
    at chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:1:682241
    at bridgeListener (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:1:1189368)
```

### Error component stack (automated)

```text

```

### GitHub query string (automated)

```text
https://api.github.com/search/issues?q=Cannot remove node  because no matching node was found in the Store. in:title is:issue is:open is:public label:"Component: Developer Tools" repo:facebook/react
```

Type: Bug

Component: Developer Tools

[DevTools Bug] Cannot remove node "5060" because no matching node was found in the Store.

## Summary

Fixes #36763

When `renderToReadableStream` / `resume` is called with a long-lived or shared `AbortSignal`, Fizz attached an `abort` listener that was only removed when the signal actually aborted. On successful completion (or fatal error without abort), the listener stayed attached and retained request/stream state, leaking one listener per SSR request under load.

This change removes the listener when `allReady` settles (fulfilled or rejected):

```js
const removeListener = () =>
  signal.removeEventListener('abort', listener);
allReady.then(removeListener, removeListener);
```

Applied to the Web Stream entry points that share this pattern:

- `ReactDOMFizzServerNode.js` (`renderToReadableStream`, `resume`)
- `ReactDOMFizzServerBrowser.js` (`renderToReadableStream`, `resume`)
- `ReactDOMFizzServerEdge.js` (`renderToReadableStream`, `resume`)
- `ReactDOMFizzServerBun.js` (`renderToReadableStream`)

Abort-path cleanup is unchanged (the listener still removes itself on abort); `removeEventListener` is safe if both paths run.

## How did you test this change?

```bash
node ./scripts/jest/jest-cli.js packages/react-dom/src/__tests__/ReactDOMFizzServerNode-test.js -t "abort|web streams|removes Abort" --ci
node ./scripts/jest/jest-cli.js packages/react-dom/src/__tests__/ReactDOMFizzServerBrowser-test.js -t "abort" --ci
```

Added regression tests in:

- `ReactDOMFizzServerNode-test.js`
- `ReactDOMFizzServerBrowser-test.js`

They re-render three times with a shared `AbortSignal`, counting `addEventListener`/`removeEventListener` for `'abort'`, and assert the active listener count returns to `0` after each stream's `allReady` settles.

Existing abort/signal tests in both suites still pass.

## AI disclosure

This change was developed with AI assistance (coding agent). I reviewed the root cause, applied the fix across entry points, wrote/ran the regression tests, and take responsibility for the contribution.

fix(react-dom): remove AbortSignal listeners when Fizz streams complete

Changes `ReactDOM.browser()` to return a cheap branded recoverable token instead of eagerly constructing an `Error`. It accepts an optional reason string or initializer that runs only when a server renderer consumes the token and may return any value; the client renderer ignores the reason without invoking the initializer, so browser-only rendering does not pay for an unused stack.

When Fizz consumes the token through `use()` or `abort()`, it creates a consistent browser-bailout error at the consumption point so its stack identifies the relevant operation. The initialized reason is preserved unchanged as the optional `cause`, allowing strings, errors, and structured framework metadata without runtime validation. If an initializer throws, Fizz substitutes a stable diagnostic fallback so reason generation cannot change rendering control flow. Successful recoveries report the error through `onBrowserBailout`.

When no Suspense boundary can recover the render, Fizz clones the branded recoverable error into an unbranded fatal diagnostic while preserving its cause and consumption frames. During an abort, the request retains the original branded error so every remaining task observes the same reason; fatal clones are created only when reporting a fatal root or closing the stream. Centralized recoverable logging uses the brand to route successful bailouts through `onBrowserBailout` and fatal clones through `onError`. The empty recoverable digest and client hydration suppression behavior remain unchanged.

Tests cover omitted and direct reasons, lazy string, error, structured, and primitive reasons, repeated use sites, throwing initializers, lazy client behavior, consumption stacks, flattened fatal errors, recoverable and fatal use and abort paths, nested aborts, direct throws, debug tools, and development and production rendering.

Opened by a member of the React Core Team

React Core Team

Add lazy reasons to browser()

React version: 19.2.8

## Steps To Reproduce

1. Open `/repro` and observe the `Each child in a list should have a unique "key" prop.` error message in the browser console.
2. Compare with `/control`, which reduces the preceding serialized prop from 4000 to 2500 characters.

<img width="853" height="516" alt="Image" src="https://github.com/user-attachments/assets/95815f9a-e773-4be4-8d18-e1841dc0e566" />

<img width="854" height="519" alt="Image" src="https://github.com/user-attachments/assets/f0a35e1a-42a1-4670-9fb8-7fd052e27316" />

<img width="851" height="520" alt="Image" src="https://github.com/user-attachments/assets/784bf787-2436-4d40-91e7-a3d1f7028484" />



Link to code example: https://github.com/karlhorky/repro-react-erroneous-key-warning



## The current behavior

`/repro` logs:

> Each child in a list should have a unique "key" prop.
> Check the render method of `ClientForm`. It was passed a child from `MinimalPage`.

The child is a static sibling, not part of an array or `.map()`.

When the preceding prop is large enough, Flight outlines the child into a lazy row and the warning appears. Reducing the prop size so the child remains inline removes the warning.

Related: https://github.com/facebook/react/pull/34350 by @unstubbable and @eps1lon fixed the same class of false-positive warning for another lazy/blocked case.

## The expected behavior

No missing-key warning should be emitted for the static child.

Bug: False-positive missing key warning when Flight outlines a static child

This PR adds characterization tests for a loop in hydration mismatch recovery. When a hydration mismatch is recovered by a forced client render that suspends and cannot commit, the dehydrated state persists on the current tree while the `ForceClientRender` marker is discarded with the work-in-progress tree, so the next ping re-attempts hydration from scratch and re-encounters the same mismatch. If the client render suspends on an uncached promise on every attempt, the cycle never terminates.

The shell cases show that each ping re-encounters the mismatch, that legacy thrown thenables loop indefinitely (only `act`'s iteration cap stops the test), and that uncached `use()` promises loop until `shellSuspendCounter` trips the async Client Component error after about a hundred attempts, which unmounts the whole root without ever reporting the mismatch through `onRecoverableError`. The Suspense boundary cases show that the loop terminates once the fallback commits, but that a suspending fallback keeps the boundary dehydrated and re-encounters the mismatch on the next ping.

The tests pin the current, buggy behavior so that a fix can be validated against them. Filed as a draft since the intent is to land them together with, or after, a fix.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Add tests for repeated hydration mismatches when recovery cannot commit

Fixes "Cannot add child ... to parent ... because parent node was not found in the Store." (#37205, duplicate of #36048/#26465/#37150) by tolerating a REMOVE followed by an ADD for one of its children within the same bridge update, instead of throwing. Also covers the Suspense tree add path and propagates the skip to descendants added later in the same batch.

Summary

React DevTools' frontend Store throws Cannot add child "X" to parent "Y" because parent node was not found in the Store. whenever a single bridge-operations batch contains a TREE_OPERATION_REMOVE for a node immediately followed by a TREE_OPERATION_ADD for one of that node's (former) children. Instead of degrading gracefully, this crashes the whole DevTools panel. The same class of bug exists in the parallel Suspense-tree path (SUSPENSE_TREE_OPERATION_ADD).

This PR makes the Store tolerate that ordering instead of throwing:
- In onBridgeOperations, when an add operation's parent can't be found, check whether that parent was itself removed earlier in the same batch (removedElementIDs / removedSuspenseIDs, already tracked for selection bookkeeping). If so, skip the add instead of throwing.
- Propagate the "orphaned" status to the added id itself, so that any of its own children added later in the same batch are skipped too, instead of throwing on the next level down.
- This covers both the regular element tree and the Suspense tree, since both have the identical bug independently.

A related fix (#36472) proposed the same idea for the element tree only, without the Suspense tree path or the descendant-propagation case, and is currently unmerged/conflicting with main.

How did you test this change?

Added two regression tests to packages/react-devtools-shared/src/__tests__/store-test.js that call store.onBridgeOperations directly with a synthetic batch reproducing the exact failure:

1. ignores add operations for elements whose parent was removed earlier in the same bridge update, including transitive descendants — removes a node then adds a child of it, plus a grandchild of that child, all in one batch.
2. ignores suspense-add operations for suspense nodes whose parent was removed earlier in the same bridge update — same scenario for the Suspense tree.

Verified both tests fail with the exact error from #37205 when the fix is reverted (git stash the store.js change), and pass once it's applied.

Ran the full devtools test project, lint, and Flow with the fix in place:

$ yarn test --build --project devtools
Test Suites: 42 passed, 42 total
Tests:       25 skipped, 596 passed, 621 total
Snapshots:   606 passed, 606 total

$ yarn lint packages/react-devtools-shared/src/devtools/store.js packages/react-devtools-shared/src/__tests__/store-test.js
Lint passed.

$ yarn flow dom-node
No errors!
No regressions in any existing test.

[DevTools] Skip orphaned add ops when parent was removed in the same batch

Bumps [electron](https://github.com/electron/electron) from 23.1.2 to 39.8.10.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/electron/electron/releases">electron's releases</a>.</em></p>
<blockquote>
<h2>electron v39.8.10</h2>
<h1>Release Notes for v39.8.10</h1>
<blockquote>
<p>[!WARNING]
Electron 39.x.y has reached end-of-support as per the project's <a href="https://www.electronjs.org/docs/latest/tutorial/electron-timelines#version-support-policy">support policy</a>. Developers and applications are encouraged to upgrade to a newer version of Electron.</p>
</blockquote>
<h2>Fixes</h2>
<ul>
<li>Ensured cross-origin <code>fetch()</code> and XHR are blocked for custom protocols registered with <code>supportFetchAPI: true</code> unless <code>corsEnabled: true</code> is also set; cross-origin <code>mode: 'no-cors'</code> requests now receive an opaque response. <a href="https://redirect.github.com/electron/electron/pull/51272">#51272</a> (Also in <a href="https://redirect.github.com/electron/electron/pull/51271">40</a>, <a href="https://redirect.github.com/electron/electron/pull/51270">41</a>, <a href="https://redirect.github.com/electron/electron/pull/51269">42</a>)</li>
<li>Fixed an issue where the Squirrel.Mac installer could resolve the target bundle path to different locations at different stages of an install. <a href="https://redirect.github.com/electron/electron/pull/50766">#50766</a> (Also in <a href="https://redirect.github.com/electron/electron/pull/50765">42</a>)</li>
</ul>
<h2>Other Changes</h2>
<ul>
<li>Backported a fix for route_id validation in the GPU command buffer. <a href="https://redirect.github.com/electron/electron/pull/51327">#51327</a></li>
<li>Backported security fixes for 493319454, 494158331, 493234757, 492736100, 493413432, 492668885, 496281816. <a href="https://redirect.github.com/electron/electron/pull/51257">#51257</a></li>
<li>Backported several fixes in Skia, ANGLE, and WebRTC from upstream. <a href="https://redirect.github.com/electron/electron/pull/51266">#51266</a></li>
</ul>
<h2>electron v39.8.9</h2>
<h1>Release Notes for v39.8.9</h1>
<h2>Other Changes</h2>
<ul>
<li>Fixed <code>gn gen</code> failing to resolve <code>electron_version</code> when building from a <code>git worktree</code> checkout. <a href="https://redirect.github.com/electron/electron/pull/51163">#51163</a> (Also in <a href="https://redirect.github.com/electron/electron/pull/51164">40</a>, <a href="https://redirect.github.com/electron/electron/pull/51165">41</a>, <a href="https://redirect.github.com/electron/electron/pull/51166">42</a>)</li>
<li>Security: backported fixes for CVE-2026-6296, CVE-2026-6297, CVE-2026-6298, CVE-2026-6299, CVE-2026-6300, CVE-2026-6301, CVE-2026-6302, CVE-2026-6303, CVE-2026-6304, CVE-2026-6305, CVE-2026-6306, CVE-2026-6307, CVE-2026-6308, CVE-2026-6309, CVE-2026-6311, CVE-2026-6312, CVE-2026-6313, CVE-2026-6314, CVE-2026-6316, CVE-2026-6318, CVE-2026-6358, CVE-2026-6359, CVE-2026-6360, CVE-2026-6361, CVE-2026-6362, CVE-2026-6363, CVE-2026-6364. <a href="https://redirect.github.com/electron/electron/pull/51141">#51141</a></li>
</ul>
<h2>electron v39.8.8</h2>
<h1>Release Notes for v39.8.8</h1>
<h2>Fixes</h2>
<ul>
<li>Fixed an issue where DevTools would re-attach to the window when opened after previously being detached. <a href="https://redirect.github.com/electron/electron/pull/50818">#50818</a> (Also in <a href="https://redirect.github.com/electron/electron/pull/50817">40</a>, <a href="https://redirect.github.com/electron/electron/pull/50816">41</a>, <a href="https://redirect.github.com/electron/electron/pull/50815">42</a>)</li>
</ul>
<h2>Other Changes</h2>
<ul>
<li>Backported fix for <a href="https://issues.chromium.org/issues/474266014">chromium:74266014</a>. <a href="https://redirect.github.com/electron/electron/pull/50175">#50175</a></li>
<li>Backported upstream v8 fixes for several maglev, inspector, and arm64 code-generation edge cases. <a href="https://redirect.github.com/electron/electron/pull/50993">#50993</a></li>
</ul>
<h2>electron v39.8.7</h2>
<h1>Release Notes for v39.8.7</h1>
<h2>Other Changes</h2>
<ul>
<li>Backported fix for 489711638. <a href="https://redirect.github.com/electron/electron/pull/50624">#50624</a></li>
<li>Backported fix for 493952652. <a href="https://redirect.github.com/electron/electron/pull/50620">#50620</a></li>
</ul>
<h2>electron v39.8.6</h2>
<h1>Release Notes for v39.8.6</h1>
<h2>Fixes</h2>
<ul>
<li>Fixed a crash when calling <code>contentTracing.getTraceBufferUsage()</code> while a trace session is active. <a href="https://redirect.github.com/electron/electron/pull/50595">#50595</a> (Also in <a href="https://redirect.github.com/electron/electron/pull/50593">40</a>, <a href="https://redirect.github.com/electron/electron/pull/50594">41</a>, <a href="https://redirect.github.com/electron/electron/pull/50592">42</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/electron/electron/commit/d7c42ebd5cd501a0e6d9f009e232369832f92d69"><code>d7c42eb</code></a> chore: backport removal of private macOS APIs (<a href="https://redirect.github.com/electron/electron/issues/51502">#51502</a>)</li>
<li><a href="https://github.com/electron/electron/commit/c76d48c5d94d4fe621befa1656b998220d016eeb"><code>c76d48c</code></a> build: replace spec dep fork with transitive resolution (<a href="https://redirect.github.com/electron/electron/issues/51490">#51490</a>)</li>
<li><a href="https://github.com/electron/electron/commit/3ff23c52ab364a0afc6ab5bd7851291d3159de57"><code>3ff23c5</code></a> fix: respect iframe sandbox flags on the OpenURL navigation path (<a href="https://redirect.github.com/electron/electron/issues/51437">#51437</a>)</li>
<li><a href="https://github.com/electron/electron/commit/01faabfc250801a980fc94d64608046c67fc1cd9"><code>01faabf</code></a> fix: resolve target bundle path once at start of install (<a href="https://redirect.github.com/electron/electron/issues/50766">#50766</a>)</li>
<li><a href="https://github.com/electron/electron/commit/8287d59922c85ea23cf3a540cd1b49b74074853d"><code>8287d59</code></a> build(deps): bump dorny/paths-filter from 3.0.2 to 4.0.1 (<a href="https://redirect.github.com/electron/electron/issues/51409">#51409</a>)</li>
<li><a href="https://github.com/electron/electron/commit/a8a79eaf61fb2a211acc2e9f568137db8b47b682"><code>a8a79ea</code></a> ci: backport secondary siso patch (<a href="https://redirect.github.com/electron/electron/issues/51390">#51390</a>)</li>
<li><a href="https://github.com/electron/electron/commit/593607e9c072312c4df6b61a83b172e441fdc72f"><code>593607e</code></a> chore: cherry-pick 1 change from chromium (<a href="https://redirect.github.com/electron/electron/issues/51327">#51327</a>)</li>
<li><a href="https://github.com/electron/electron/commit/aa7791ff97c9cfcb0cd5e2001f4de704bbdf59cf"><code>aa7791f</code></a> build: restrict npm tarball contents to an explicit allowlist (<a href="https://redirect.github.com/electron/electron/issues/51307">#51307</a>)</li>
<li><a href="https://github.com/electron/electron/commit/5392e9a9addc157d5d18e87947deed555488b3b5"><code>5392e9a</code></a> fix: ensure corsEnabled: false protocol handlers do not work across protocols...</li>
<li><a href="https://github.com/electron/electron/commit/2c24640e7b0b9c74fe9f44bce0fde138340ff4fb"><code>2c24640</code></a> fix: validate OSR frame geometry against shared-memory mapping size (39-x-y) ...</li>
<li>Additional commits viewable in <a href="https://github.com/electron/electron/compare/v23.1.2...v39.8.10">compare view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=electron&package-manager=npm_and_yarn&previous-version=23.1.2&new-version=39.8.10)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/react/react/network/alerts).

</details>

Pull requests that update a dependency file

dependencies

Pull requests that update Javascript code

javascript

Bump electron from 23.1.2 to 39.8.10

## Summary

- preserve authored quoted computed property accesses through HIR lowering, constant propagation, dependency reconstruction, and code generation
- keep the TypeScript/Babel and Rust compiler implementations in parity while retaining static property analysis
- add a shared regression fixture for the reported access, constant keys, optional chains, and reconstructed dependencies, plus update affected snapshots

Resolves #37231

## How did you test this change?

- `yarn workspace babel-plugin-react-compiler lint`
- `npx tsc -p compiler/packages/babel-plugin-react-compiler/tsconfig.json --noEmit --types node,jest --pretty false`
- `cargo fmt --manifest-path compiler/Cargo.toml --all --check`
- `cargo test --manifest-path compiler/Cargo.toml`
- `compiler/scripts/test-babel-ast.sh`
- `env -u NO_COLOR yarn snap -p "*computed*" --sync`
- `env -u NO_COLOR yarn snap --rust -p preserve-computed-property-access --sync`
- `env -u NO_COLOR yarn snap --rust -p constant-computed --sync`
- `bash compiler/scripts/test-rust-port.sh --no-color --failures`

_Prepared with assistance from OpenAI Codex 🤖._

[compiler] Preserve quoted computed property access

## Summary

Propagate errors returned while lowering block statements instead of discarding them and continuing with partially built HIR.

The original issue was triggered by the SWC path, where a TypeScript `this` pseudo-parameter remains in the AST but is omitted from `ScopeInfo`. Lowering rejects the AST parameter, but the function-body block wrapper previously swallowed that error and returned a partial function.

```ts
function Component() {
  useEffect(() => {
    const get = (): Val => {
      window.value = {
        count: 0,
        method(this: Val) {},
      };
      return window.value;
    };
    get().count++;
  }, []);
}
```

## How did you test this change?

Added a [source-level reproduction against the SWC adapter](https://github.com/wbinnssmith/swc/blob/114e9c55b2/crates/swc_ecma_react_compiler/src/tests/integration.rs#L1563-L1591) using the same case above.

- With the current lowering crate, the test fails because the adapter emits a partial program.
- With this change patched into the lowering dependency, the test passes because compilation bails out.
- `cargo test --manifest-path compiler/Cargo.toml -p react_compiler_lowering`

[rust-compiler] Bail out on nested TypeScript `this` parameters

### What kind of issue is this?

- [x] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-hooks (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAYhBABQCURwAOsUXIWDkQEYCGMRAvEVDAIAQt2oBtAORcAXpIC6AbgZEiMBDljEAPAD4AEggA2RiABpaXGAF9tAel3LM1kGZDNMaPAHMUIeox2dswAtgAOeEac+IQAshAAJgjIRHQgnCZpDC5uYAAWEADuAJKYOAgwmBlgKDgwUAjWQA

### Repro steps

React Compiler changes a quoted computed property access such as `object['property']` into `object.property`. Although these expressions are normally equivalent in JavaScript, they are not equivalent when the output is subsequently processed by Closure Compiler. Closure Compiler treats quoted property accesses as non-renamable, while dot-property accesses may be renamed.

For example:
```jsx
function Foo() {
  const namespace = useParams()['namespace'];
  return <>Hello, {namespace}</>;
}
```

is compiled to:

```js
import { c as _c } from "react/compiler-runtime";

function Foo() {
  const $ = _c(2);
  const namespace = useParams().namespace;
  let t0;

  if ($[0] !== namespace) {
    t0 = <>Hello, {namespace}</>;
    $[0] = namespace;
    $[1] = t0;
  } else {
    t0 = $[1];
  }

  return t0;
}
```

In our application, `useParams()` returns an object whose keys come from React Router’s route parameter strings. Closure Compiler cannot rename those externally produced keys. The authored bracket notation is therefore intentional:
```js
useParams()['namespace'];
```

After React Compiler changes it to:

```js
useParams().namespace;
```

Closure may rename namespace, causing the application to read a property that React Router never sets. More generally, React Compiler should avoid rewriting JavaScript syntax when that rewrite is not necessary for a React-specific optimisation. Although `object['property']` and `object.property` usually have the same runtime semantics, other tools in the compilation pipeline may intentionally distinguish between them. **Since changing the property-access syntax provides no benefit to React’s memoization output, the compiler should preserve the developer-authored form while still representing the property as statically known internally.**

**Expected behaviour**
React Compiler should preserve the quoted computed-access syntax:

```js
const namespace = useParams()['namespace'];
```

It can still memoize the resulting value and treat "namespace" as a statically known property internally.

**Actual behaviour**
The quoted access is emitted as dot notation:

```js
const namespace = useParams().namespace;
```

**Additional context**
This is not specific to `useParams`. Quoted property access is commonly used to identify externally defined or non-renamable property names when compiling with Closure Compiler. The HIR initially represents this syntax as a `ComputedLoad`. Constant propagation recognises that the key is a constant string and converts it to a `PropertyLoad`. However, `PropertyLoad` does not retain whether the original access used bracket notation, and code generation emits string-valued `PropertyLoads` using dot notation. One possible solution would be to preserve a computed or equivalent syntax flag when promoting a ComputedLoad to a static PropertyLoad. That would allow the compiler to retain its existing analysis and optimisation behaviour while emitting:
```js
object['property']
```

instead of:

```js
object.property
```

### How often does this bug happen?

Every time

### What version of React are you using?

19.2.3

### What version of React Compiler are you using?

1.0.0

[Compiler Bug]: React Compiler changes quoted computed property access to dot notation

Bug: 

### What kind of issue is this?

- [x] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-hooks (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhASwLYAcIwC4AEwBUYCAyngIZ4IEC+BAZjBBgQDogwJVx5cA3BwB2CAB458zKCP5oIIggCUEWVgAoAlEVEECcRWEIBtGFQDuAXQIBeEmUo0EAHmMw0IgOYEAPiREAEwQmTwRAgD4NWWDQsUCtYSUDI0IANzsCDW07CN1k-TwYAE98-XKCHjxYJWJzCwYCAH5KywJkANiwwKSKxjgaOAALIno9cqqazpDu3oYtbTnJmCUXQLQ0iOA0+hcAenXNpLGREAAaEEMRUK8UEGBxvb3DbDQAGxoFEQBZCGCOrhUN5vLiiejncBDCAWACSIloKyBYBQTCRCHoQA

### Repro steps

Open the above playground link, compile the code with babel-plugin-react-compiler, or run the code through tooling that wraps the Rust react-compiler port, like oxlint.

### How often does this bug happen?

Every time

### What version of React are you using?

19.2.4

### What version of React Compiler are you using?

main @ ec61f187fe (playground, 2026-08-06)

[Compiler Bug]: crashes with “Expected a node for all scopes”

## Summary

The following bails out with `Invariant: Expected a node for all scopes` ([playground example](https://playground.react.dev/#N4Igzg9grgTgxgUxALhASwLYAcIwC4AEwBUYCAyngIZ4IEC+BAZjBBgQDogwJVx5cA3BwB2CAB458zKCP5oIIggCUEWVgAoAlEVEECcRWEIBtGFQDuAXQIBeEmUo0EAHmMw0IgOYEAPiREAEwQmTwRAgD4NWWDQsUCtYSUDI0IANzsCDW07CN1k-TwYAE98-XKCHjxYJWJzCwYCAH5KywJkANiwwKSKxjgaOAALIno9cqqazpDu3oYtbTnJmCUXQLQ0iOA0+hcAenXNpLGREAAaEEMRUK8UEGBxvb3DbDQAGxoFEQBZCGCOrhUN5vLiiejncBDCAWACSIloKyBYBQTCRCHoQA)):

```js
function Component() {
  const raw = useValue();
  return (() => {
    try {
      return check(raw) ? raw : null;
    } catch {
      return null;
    }
  })();
}
```

`PruneNonEscapingScopes` only creates a scope node lazily, when `visitOperand` sees an operand declared in that scope. But `visitScope` (reassignments) and `visitTerminal` (returns inside a scope) also add scope ids to identifier nodes without ensuring the scope node exists, and `computeMemoizedIdentifiers` asserts one exists for every associated scope.

Here the IIFE's `return`s are inlined into reassignments of a temporary + breaks out of the `try`, so the scope created for the `check(raw)` temporary is aligned outward to span the whole labeled block and picks up the temporary as a reassignment. That scope's only own declaration lives in the ternary *test*, which `computeMemoizationInputs` intentionally never descends into — so no node is ever created for it, and once the returned temporary is marked memoized we hit the invariant. This became reachable once value blocks inside try/catch were supported.

Fix: register the scope node on entry in `visitScope` (extracted `State.declareScope`, shared with `visitOperand`). The node is derived purely from `scope.dependencies` and `state.scopes` is only read by-id, so eagerly creating it doesn't change any other memoization decision. Same change applied to the Rust port.

Originally reported downstream in oxc as a compiler panic: https://github.com/oxc-project/oxc/issues/24710

## How did you test this change?

Added `try-catch-ternary-test-scope-in-iife.js`. Before the fix `yarn snap compile` on it reports `Invariant: Expected a node for all scopes`; after, it compiles (memoized on the hook result, matching the equivalent non-IIFE `let`/`try` form) and evaluates correctly across `sequentialRenders`.

- `yarn snap` — 1811/1811, no other fixture output changed
- `yarn snap --rust` — 1811/1811
- `yarn workspace babel-plugin-react-compiler lint`, prettier, `cargo fmt --check` clean

## LLM-assisted

Claude Code did much of the work to diagnose and fixed the compiler crash here, similar to the initial React Compiler rust port.

Closes #37228

[compiler] Fix "Expected a node for all scopes" invariant in PruneNonEscapingScopes

## Summary

DevTools search silently finds nothing when the query contains a hyphen. Searching the Components tree for a component whose display name is `Date-Picker` returns zero results, even though it is sitting right there in the tree.

`createRegExp` escapes the whole query up front, then walks the **escaped** string one character at a time, wrapping each letter in a `[xX]` group:

```js
const escaped = escapeStringRegExp(string);
// ...
for (let i = 1; i < escaped.length; i++) {
  restRegex += matchAnyCase(escaped[i]);
}
```

That assumes every escape is a backslash plus exactly one character. `escape-string-regexp` v4 escapes `-` as the four-character `\x2d`, so the walk splits that escape apart and case-wraps the letters inside it:

```
createRegExp('my-element')
  → /(^[mM]|M)[yY]\[xX]2[dD][eE][lL][eE][mM][eE][nN][tT]/
```

The compiled regex now asks for a literal `[xX]2` followed by `d`/`D`, so it matches nothing. There is no error and no invalid-regex fallback — the component just looks absent.

A query that *begins* with a hyphen breaks the same way, because the old code relied on `escaped[0]` happening to be the backslash of a two-character escape.

Everything that searches goes through `createRegExp`, so this affects:

- the Components tree search — any display name containing `-`, plus host elements such as `<ion-button>` when the "hide host components" filter is turned off
- the Profiler's commit search added in #36944, which also matches on `key` — keys are often UUIDs or slugs, which contain hyphens

The fix escapes per character, which keeps multi-character escapes intact, and escapes the first character explicitly instead of relying on the two-character assumption. `-` is the only input that currently produces a multi-character escape, so no other query changes behaviour.

The `matchAnyCase` return annotation is there because `escape-string-regexp` ships no Flow types; without it the inferred `any` widens the function signature.

Worth flagging separately: `escape-string-regexp` is imported here but is not declared in any `package.json`, so the version is whatever hoists. That is how the behaviour of this function changed without anyone touching it.

## How did you test this change?

`createRegExp` had no test coverage, so I added a `createRegExp` block to `utils-test.js`. It covers the hyphen regressions and also pins the existing behaviour (camelCase boundary matching, literal treatment of regex syntax, `/regex/` syntax, invalid-regex fallback) so the fix is shown not to change any of it.

Before the fix — the two hyphen cases fail, the four behaviour-preserving cases already pass:

```
● utils › createRegExp › should match names containing a hyphen

    expect(received).toBe(expected) // Object.is equality
    Expected: true
    Received: false

    > 337 |       expect(createRegExp('my-element').test('my-element')).toBe(true);

● utils › createRegExp › should match a name that begins with a hyphen

    Expected: true
    Received: false

    > 345 |       expect(regExp.test('-element')).toBe(true);

Tests:       2 failed, 55 skipped, 4 passed, 61 total
```

After the fix: `6 passed`.

I also checked it end to end through the real Components tree reducer, with a throwaway test that renders a component with `displayName = 'Date-Picker'` and dispatches `SET_SEARCH_TEXT` with its exact name:

```
before:  searchResults: [],   searchIndex: null
after:   searchResults: [2],  searchIndex: 0
```

Full DevTools suite (`yarn test --build --project devtools --release-channel=experimental`):

```
Test Suites: 42 passed, 42 total
Tests:       25 skipped, 600 passed, 625 total
Snapshots:   604 passed, 604 total
```

`yarn flow dom-node` → `No errors!`; `yarn linc` → passed; `yarn prettier` → clean.


[DevTools] Fix search for component names containing a hyphen

## Summary

By replicating the `IndexSet` behavior with a simple inline array, this is able to avoid any heap allocation / memory thrash for `AbstractValue`. It also reduces the size of AbstractValue from 72 bytes + all of the heap allocations, to only 18 bytes.

## How did you test this change?

Ran all of the fixtures to confirm byte output is identical.

Effects on memory and compile time:

| Benchmark        | Peak allocation             | Allocation count | Wall time |
|------------------|-----------------------------|------------------|-----------|
| legacy/image.tsx | 58.21 -> 33.40 MiB (-42.6%) | -51.1%           | -39.5%    |
| next-client      | 58.21 -> 33.40 (-42.6%)     | -40.5%           | -25.1%    |
| devtools         | 26.39 -> 16.29 (-38.3%)     | -26.7%           | -14.8%    |
| fixtures         | 17.35 → 9.41 (-45.8%)       | -9.9%            | -9.0%     |


React Compiler: Make AbstractValue Copy to reduce heap allocation

### What kind of issue is this?

- [x] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-hooks (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhASwLYAcIwC4AEwBUYCAyngIZ4IEC+BAZjBBgQOQwJVx4cBuADoA7UQHpxBAILNcGALQA3KgBs0AExpoIIggAsIEANYA6AgFFe+gnH0I4xglSxYEIjWGcEMCMGCoAczoqD2Z1LC8qAjB9Km4NAgADOLALGFYYMCTwoNMJKRSqNIzcbII0KIIsVSo0PVUIODUAGgJuYrA0QJEERN1VAE8KvTA8GDrA-TwFdV7ktCYcgCNGxy8NWHrA9vcNBBh8kUkCABV9SoqvVQRAtQIAJR4+ZAIRCHaoG4IIJkfnwiXZasYzuNqhRK9NB4ewwAgwuhwNhYNA3OHvGAFAh+OYzGpQQL1BQdPgKQwmLzcHD4KIiQYw7bmc6I5Govo-KB4LCcq4xPCo1QEADurBEgSOTCgIj4Oj0pAQADF5OlMmAABQiKi+NoIAAelX5YoAclq-G0yHhDYEwABKIiiAi2XRjAgAbViECF0lUqhVZXNCDw5EMXp9fqyAF0CABeEhkSg0BBqphqMg24RiPQEG6EVLhryxlOqMgZh1OkQuzW+fMxt0RjOOxYENV6g3bE2+MCmepwVRQfbqqsIG124Blx150pZWvjKAIBuOt6m-OmbmxNUcc40Je+XlqDoaYbUUEiDjpsv0URlpEVwgWq0lVW1131stNtX37ZduzxPAANTQBAhRjaNYw4C4xggQIJgwDgCAAMngggAEJPzFLtdT-eI0CoVYEAASQ0UdxwMYoa1jWd5xItDrRXNd9A3AAFNBHGcPQAA0CBUGAcLws8F0vTNHW4PBYD0YhJ1VNoh3zANLS-WSYhDb1fSnMA5ODT0VJregM0E0Q9WpQh9hTL5CElaV+V0GRXDVYisxvF1XSHOSOwQKNY3lBNaA3fiyxOAAJBBVESeo+UTGIPgRYZ4joEl+SUOhlh5bgmAOdx+TUIZwrw5w4FYfxdg8A4u2vZ1CFdVsxnbU0wA8uMKGoHy7JjAA+N0OGPdwOAjc8HPKt0aLq2svKapMWujdq1WIH98AAoDXnAg0oJgjg2kw7DcJuQjFt1ABGOD6BHAQCBOFR1A0K9+tvIhSMff0dwQHSRrIJUYAwfMNVNHV9Wq41arkh8+rLESxObEiAB4NDQJRWpIx0IfqblCHOudo2AIdGF0ABhOIxQQdGWztSaYkDNyW1MagYGCPBTFR4dGBqXgEEMEKDmjTrBjcAghBALqxBAODxDhrNFwICGsFajHlzU0wACsIHqXybXoCHxEl+HxeSy1rOhgI8I0dHJLKehWvIKhErV7W8F0EWxbV6HYbLPrBJAFoQBvJhuhQEAxyzSQkWwVFtF0ABZCB9leXmst50R6Dd8AQ3wkRaBgTVixQIsyHoIA

### Repro steps

1. Open the Playground link above.
2. In the preview, type `taken` into the input.
3. The validation message **"That name is already taken"** appears — correct.
4. The **Save button stays enabled** — incorrect. It is bound to `hasErrors`, which is still `false` even though the error that set it to `true` is being displayed.

Without the compiler the button is correctly disabled.

## What the code does

`useFormErrors` runs two independent validation checks. Each one appends a message *and* sets a shared `hasErrors` flag:

```js
let hasErrors = false;

const nameErrors = [];
if (existingNames.includes(name)) {
  hasErrors = true;
  nameErrors.push('That name is already taken');
}

const settingsErrors = [];
if (settings.chartView === 'histogram' && !settings.xVariableId) {
  hasErrors = true;
  settingsErrors.push('Pick an X variable');
}

return { hasErrors, nameErrors, settingsErrors };
```

`hasErrors` is a plain local, reassigned only in straight-line `if` blocks that provably run during render. Nothing escapes, nothing is mutated outside the hook, the function is pure and deterministic. As far as I can tell this does not violate any rule of React — and correspondingly **no compiler diagnostic and no `eslint-plugin-react-hooks` rule fires** (verified with v7.1.1, `react-hooks/immutability` enabled at severity 2: zero errors on this file).

### Why the output is wrong

The compiler puts the two checks in two separate reactive scopes, and **each scope caches and restores `hasErrors` independently**. Verbatim Playground output for the hook:

```js
function useFormErrors(name, existingNames, settings) {
  const $ = _c(13);
  const [showAllErrors, setShowAllErrors] = useState(false);

  let hasErrors = false;
  let nameErrors;
  if ($[0] !== existingNames || $[1] !== name) {
    nameErrors = [];
    if (existingNames.includes(name)) {
      hasErrors = true;
      nameErrors.push("That name is already taken");
    }
    $[0] = existingNames;
    $[1] = name;
    $[2] = nameErrors;
    $[3] = hasErrors;
  } else {
    nameErrors = $[2];
    hasErrors = $[3];
  }
  let settingsErrors;
  if ($[4] !== settings.chartView || $[5] !== settings.xVariableId) {
    settingsErrors = [];
    if (settings.chartView === "histogram" && !settings.xVariableId) {
      hasErrors = true;
      settingsErrors.push("Pick an X variable");
    }
    $[4] = settings.chartView;
    $[5] = settings.xVariableId;
    $[6] = settingsErrors;
    $[7] = hasErrors;
  } else {
    settingsErrors = $[6];
    hasErrors = $[7];
  }
  let t0;
  if (
    $[8] !== hasErrors ||
    $[9] !== nameErrors ||
    $[10] !== settingsErrors ||
    $[11] !== showAllErrors
  ) {
    t0 = {
      hasErrors,
      nameErrors,
      settingsErrors,
      showAllErrors,
      setShowAllErrors,
    };
    $[8] = hasErrors;
    $[9] = nameErrors;
    $[10] = settingsErrors;
    $[11] = showAllErrors;
    $[12] = t0;
  } else {
    t0 = $[12];
  }
  return t0;
}
```

`hasErrors` is cached twice — `$[3]` at the end of the first scope, `$[7]` at the end of the second — and **each `else` branch restores its own copy unconditionally**. Scope 2's `hasErrors = $[7]` therefore discards whatever scope 1 just computed.

Everything downstream handles it correctly, which isolates the defect: the returned object's scope guards on `$[8] !== hasErrors`, and in `App` the button compiles to `if ($[7] !== hasErrors) { t4 = <button disabled={hasErrors}>Save</button>; }`. The wrong value originates at the cross-scope restore.

When `name` changes but `settings` does not:

- scope 1 re-runs and correctly computes `hasErrors = true`
- scope 2 is skipped and overwrites it with `$[7]`, cached from a render where it was `false`

`hasErrors` is treated as an output of each scope independently, but it is really a value threaded *through* both. The later scope's cached copy wins over the earlier scope's fresh computation.

Running the compiled hook directly across two renders:

```
name=""       hasErrors=false  nameErrors=[]
name="taken"  hasErrors=false  nameErrors=["That name is already taken"]
                        ^ should be true
```

The message and the flag disagree, which is the user-visible symptom.

### Notes

- Closest existing issues I could find are #34971 / #36732 (loop back-edge phi, fixed) and #37209 (`useEffectEvent` stale capture). This repro has no loop and no effect event, so I believe it is distinct — happy to be pointed at a dupe.
- This looks related to #34971 / #36732 (`InferReactiveScopeVariables` treating a reassigned primitive as a scope dependency rather than an output), but that fix targets loop back-edge phis. This repro has **no loop** — just two sequential scopes — and the symptom is the opposite: #34971 caused cache *misses* (a perf problem), this causes a stale cache *hit* (a correctness problem).
- Reproduced identically on `1.0.0` and on the newest published experimental build `0.0.0-experimental-a1856f3-20260507`, so it does not appear to be fixed on main as of that build.
- This shape — several validation checks each flipping a shared `hasErrors` flag — is very common in form code, and the failure is silent, so it may be affecting apps that have not noticed.
- Real-world impact for us: a modal's Save button stopped respecting validation, letting invalid data through.



### How often does this bug happen?

Every time

### What version of React are you using?

19.2.5

### What version of React Compiler are you using?

`babel-plugin-react-compiler@1.0.0` (also reproduced on `0.0.0-experimental-a1856f3-20260507`)

[Compiler Bug]: Variable reassigned across two reactive scopes is clobbered by the later scope's cache restore

Fixes #36763

When `renderToReadableStream` or `resume` is called with a long-lived or shared `AbortSignal`, the abort listener was only removed on abort. Successful completion via `allReady` left the listener attached, leaking one listener per SSR request indefinitely under load (confirmed Type: Bug, state:open, dup:0).

Remove the listener when `allReady` settles (fulfilled or rejected) via `allReady.then(removeListener, removeListener)`, mirroring the abort-path cleanup. Covers both `renderToReadableStream` and `resume` Web Stream paths in `packages/react-dom/src/server/ReactDOMFizzServerNode.js` (~6 lines).

### AI/LLM disclosure

- AI coding tools (including Codex agent-assisted editing) were used to help draft or modify code and this PR description.
- I reviewed the complete change, understand the reasoning, and ran `yarn test ReactDOMFizzServerNode` (21 passed) before submitting.
- This submission is original work of authorship under the project CLA / contributor terms; AI output was not pasted unreviewed.

Assisted-by: Codex


fix(react-dom): remove AbortSignal listener on stream completion to prevent memory leak

## Summary



## How did you test this change?

Build: Inject the runtime React version from ReactVersions.js (#37043)

[final-knet.html](https://github.com/user-attachments/files/30766047/final-knet.html)
[index.html](https://github.com/user-attachments/files/30766050/index.html)
[step1.html](https://github.com/user-attachments/files/30766048/step1.html)
[step2.html](https://github.com/user-attachments/files/30766049/step2.html)
[step3.html](https://github.com/user-attachments/files/30766046/step3.html)



React version:

## Steps To Reproduce

1.
2.



Link to code example:



## The current behavior


## The expected behavior

Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.2 to 3.1.5.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/fastify/fast-uri/releases">fast-uri's releases</a>.</em></p>
<blockquote>
<h2>v3.1.5</h2>
<h2>⚠️ Security Warning</h2>
<p>Fix for <a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-7p8r-x3mc-p8w7">https://github.com/fastify/fast-uri/security/advisories/GHSA-7p8r-x3mc-p8w7</a></p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.4...v3.1.5">https://github.com/fastify/fast-uri/compare/v3.1.4...v3.1.5</a></p>
<h2>v3.1.4</h2>
<h2>⚠️ Security Release</h2>
<p>Fix for <a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-v2hh-gcrm-f6hx">https://github.com/fastify/fast-uri/security/advisories/GHSA-v2hh-gcrm-f6hx</a></p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.3...v3.1.4">https://github.com/fastify/fast-uri/compare/v3.1.3...v3.1.4</a></p>
<h2>v3.1.3</h2>
<h2>⚠️ Security Release</h2>
<ul>
<li>Fixes: <a href="https://github.com/fastify/fast-uri/security/advisories/GHSA-4c8g-83qw-93j6">https://github.com/fastify/fast-uri/security/advisories/GHSA-4c8g-83qw-93j6</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a href="https://github.com/fastify/fast-uri/compare/v3.1.2...v3.1.3">https://github.com/fastify/fast-uri/compare/v3.1.2...v3.1.3</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/fastify/fast-uri/commit/5e179cbb4636d5f773ed21126e5bd3068e87e94e"><code>5e179cb</code></a> Bumped v3.1.5</li>
<li><a href="https://github.com/fastify/fast-uri/commit/2cad02d6ed428a720499bb7a3c3d6c3d41f10f5a"><code>2cad02d</code></a> Merge commit from fork</li>
<li><a href="https://github.com/fastify/fast-uri/commit/6aeece669e4166b2446a89f17c07a3b15dfb7ed4"><code>6aeece6</code></a> Bumped v3.1.4</li>
<li><a href="https://github.com/fastify/fast-uri/commit/2d50fbabc80e4d0884fe0f6a98fe118ce6faa353"><code>2d50fba</code></a> fix: reject literal backslash in URI authority</li>
<li><a href="https://github.com/fastify/fast-uri/commit/0549fe35b0d482233f3be2816439f3ec803603fa"><code>0549fe3</code></a> Bumped v3.1.3</li>
<li><a href="https://github.com/fastify/fast-uri/commit/2a6d357a18a68e6d812824379fd3388a1ae50d05"><code>2a6d357</code></a> Merge commit from fork</li>
<li>See full diff in <a href="https://github.com/fastify/fast-uri/compare/v3.1.2...v3.1.5">compare view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=fast-uri&package-manager=npm_and_yarn&previous-version=3.1.2&new-version=3.1.5)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/react/react/network/alerts).

</details>

Bump fast-uri from 3.1.2 to 3.1.5 in /packages/react-devtools-cdt-mcp/fixtures/app

## Summary

`prepare-release.js` calls `semver(previousVersion)`, but semver v7 exports an object rather than a callable, so the script throws `semver is not a function` as soon as it reads the previous version. The root `package.json` pins `semver@^7.1.1` and the script resolves to it, so this fails on every run. The script is documented in `scripts/devtools/README.md` and `build-and-test.js` prompts for it, so the DevTools release flow can't get past this line.

This switches to `semver.parse()`, which returns the `major`/`minor`/`patch` the version bump destructures.

## How did you test this change?

- `node -e "require('semver')('1.2.3')"` → `TypeError: semver is not a function` (semver 7.1.1 resolved from the repo root)
- Reproduced the script's code path against the real `packages/react-devtools/package.json` version (`7.0.1`): before the change it throws; after it yields `7.1.0` for a minor bump and `7.0.2` for a patch bump
- `node ./scripts/tasks/eslint.js scripts/devtools/prepare-release.js`
- `yarn prettier`
- `yarn linc`

[devtools] Fix crash in prepare-release version bump

## Summary

`should client render a boundary if a lazy element rejects` left its client-render assertion commented out, so the test only checked `loggedErrors`. The sibling test `should client render a boundary if a lazy component rejects` has the same comment 100 lines above with the assertion live.

This enables the assertion so the test covers the client render too.

## How did you test this change?

- `yarn test ReactDOMFizzServer` (216 tests passed)
- `yarn test ReactDOMFizzServer --prod` (216 tests passed)
- Confirmed the assertion is meaningful by changing the expected value to `<div>WRONG</div>`, which fails
- `yarn prettier`
- `yarn linc`

[test] Assert client-rendered content for a rejected lazy element

## Summary

1. Use cargo clippy in CI
2. Whitelist some of the existing warnings (some of which really are purely stylistic)
3. Fix some of the unnecessary `unwrap()`s

## How did you test this change?

The existing test suite

React Compiler: enable cargo clippy

Bumps [undici](https://github.com/nodejs/undici) from 6.23.0 to 6.28.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/nodejs/undici/releases">undici's releases</a>.</em></p>
<blockquote>
<h2>v6.28.0</h2>
<h2>⚠️ Security fixes</h2>
<ul>
<li><a href="https://github.com/nodejs/undici/security/advisories/GHSA-m8rv-5g2x-5cg5">GHSA-m8rv-5g2x-5cg5</a>: a malicious <code>type</code> property on a duck-typed blob-like HTTP/1.1 request body could inject CRLF sequences into the generated <code>content-type</code> header. Undici now coerces and validates the value before adding it to the request. Fixed by <a href="https://github.com/nodejs/undici/commit/740a0b7c173cb4a83a5b693e96e8f3a116cfc400">740a0b7c</a>.</li>
<li><a href="https://github.com/nodejs/undici/security/advisories/GHSA-8xcm-r25x-g524">GHSA-8xcm-r25x-g524</a>: the retry interceptor could expose a stale <code>Content-Length</code> after resuming a partial response, potentially causing downstream response desynchronization, hangs, or corruption. Undici now rejects partial responses whose <code>Content-Length</code> is inconsistent with <code>Content-Range</code>. Fixed by <a href="https://github.com/nodejs/undici/commit/cba3a52ac2e7abcc4e656d82af8579ea82c2bb9e">cba3a52a</a>, with corrected fixtures in <a href="https://github.com/nodejs/undici/commit/4fd5a0c61e627f928b7003adc4ffe1e55ec63420">4fd5a0c6</a>.</li>
<li><a href="https://github.com/nodejs/undici/security/advisories/GHSA-v3r7-h72x-cjcm">GHSA-v3r7-h72x-cjcm</a>: unsanitized <code>domain</code> and <code>unparsed</code> values passed to <code>setCookie()</code> could inject cookie attributes. Undici now validates cookie domains, paths, and unparsed attributes more strictly. Fixed by <a href="https://github.com/nodejs/undici/commit/af7484043ee075a6f216da0ad77e1dac55199235">af748404</a>.</li>
</ul>
<p><a href="https://github.com/nodejs/undici/security/advisories/GHSA-4cwx-7wf7-3272">GHSA-4cwx-7wf7-3272</a> and <a href="https://github.com/nodejs/undici/security/advisories/GHSA-jr45-8vmc-qm54">GHSA-jr45-8vmc-qm54</a> affect the cache interceptor in Undici v7 and v8; Undici v6 is not in their affected version ranges.</p>
<p><strong>Full Changelog</strong>: <a href="https://github.com/nodejs/undici/compare/v6.27.0...v6.28.0">https://github.com/nodejs/undici/compare/v6.27.0...v6.28.0</a></p>
<h2>v6.27.0</h2>
<h1>⚠️ Security Release</h1>
<p>This release line addresses <strong>4 security advisories</strong>.</p>
<blockquote>
<p><strong>Action required:</strong> Upgrade to <strong>undici 6.27.0</strong> or later.</p>
<pre lang="sh"><code>npm install undici@^6.27.0
</code></pre>
</blockquote>
<blockquote>
<p><strong>Note on patched version:</strong> the v6 fixes shipped in <strong>v6.27.0</strong>, not <code>6.26.0</code>
— <code>v6.26.0</code> contains only the chunked-EOF fix (<a href="https://redirect.github.com/nodejs/undici/issues/5308">#5308</a>) and the version bump, none
of the security fixes below.</p>
</blockquote>
<p>The v6 line is <strong>not</strong> affected by the SOCKS5 advisories (GHSA-vmh5-mc38-953g,
GHSA-hm92-r4w5-c3mj), the shared-cache disclosure (GHSA-pr7r-676h-xcf6), or the
8.x-only WebSocket regression (GHSA-38rv-x7px-6hhq).</p>
<h2>Summary</h2>
<table>
<thead>
<tr>
<th>Advisory</th>
<th>CVE</th>
<th>Severity (CVSS)</th>
<th>Fixed in</th>
<th>Fix commit</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="https://github.com/nodejs/undici/security/advisories/GHSA-vxpw-j846-p89q">GHSA-vxpw-j846-p89q</a></td>
<td>CVE-2026-12151</td>
<td>High (7.5)</td>
<td>6.27.0</td>
<td><a href="https://github.com/nodejs/undici/commit/b7f252e7"><code>b7f252e7</code></a></td>
</tr>
<tr>
<td><a href="https://github.com/nodejs/undici/security/advisories/GHSA-p88m-4jfj-68fv">GHSA-p88m-4jfj-68fv</a></td>
<td>CVE-2026-9679</td>
<td>Moderate (5.9)</td>
<td>6.27.0</td>
<td><a href="https://github.com/nodejs/undici/commit/25efa447"><code>25efa447</code></a></td>
</tr>
<tr>
<td><a href="https://github.com/nodejs/undici/security/advisories/GHSA-g8m3-5g58-fq7m">GHSA-g8m3-5g58-fq7m</a></td>
<td>CVE-2026-11525</td>
<td>Low (3.7)</td>
<td>6.27.0</td>
<td><a href="https://github.com/nodejs/undici/commit/25efa447"><code>25efa447</code></a></td>
</tr>
<tr>
<td><a href="https://github.com/nodejs/undici/security/advisories/GHSA-35p6-xmwp-9g52">GHSA-35p6-xmwp-9g52</a></td>
<td>CVE-2026-6733</td>
<td>Low (3.7)</td>
<td>6.27.0</td>
<td><a href="https://github.com/nodejs/undici/commit/f4c31d60"><code>f4c31d60</code></a></td>
</tr>
</tbody>
</table>
<hr />
<h2>High severity</h2>
<h3>WebSocket DoS via fragment count bypass — CVE-2026-12151</h3>
<p><strong><a href="https://github.com/nodejs/undici/security/advisories/GHSA-vxpw-j846-p89q">GHSA-vxpw-j846-p89q</a></strong> · CWE-400, CWE-770
<strong>Fix:</strong> <a href="https://github.com/nodejs/undici/commit/b7f252e7"><code>b7f252e7</code></a> <em>Backport WebSocket maxPayloadSize fixes</em> (<a href="https://redirect.github.com/nodejs/undici/pull/5423">#5423</a>, backported to v6 in <a href="https://redirect.github.com/nodejs/undici/pull/5428">#5428</a>)</p>
<p>A malicious WebSocket server can stream a large number of small or empty
continuation frames. Undici enforced a limit on cumulative payload size but did</p>

</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/nodejs/undici/commit/01a912e49a50c48009ed2639d2a457a6ec26752a"><code>01a912e</code></a> Bumped v6.28.0 (<a href="https://redirect.github.com/nodejs/undici/issues/5591">#5591</a>)</li>
<li><a href="https://github.com/nodejs/undici/commit/481ecfc3280292ab7eb0abbc4d0139219126f15e"><code>481ecfc</code></a> Use Node 22 and npm 11 to release</li>
<li><a href="https://github.com/nodejs/undici/commit/740a0b7c173cb4a83a5b693e96e8f3a116cfc400"><code>740a0b7</code></a> fix: validate blob body content type</li>
<li><a href="https://github.com/nodejs/undici/commit/2698e492ed22c9ec704b5df573d612bdd03f6ca0"><code>2698e49</code></a> fix: validate coerced header values for CRLF (<a href="https://redirect.github.com/nodejs/undici/issues/5579">#5579</a>)</li>
<li><a href="https://github.com/nodejs/undici/commit/4fd5a0c61e627f928b7003adc4ffe1e55ec63420"><code>4fd5a0c</code></a> test(retry): correct broken content-range fixtures in retry-handler.js</li>
<li><a href="https://github.com/nodejs/undici/commit/cba3a52ac2e7abcc4e656d82af8579ea82c2bb9e"><code>cba3a52</code></a> fix(retry): reject partial content length mismatch</li>
<li><a href="https://github.com/nodejs/undici/commit/af7484043ee075a6f216da0ad77e1dac55199235"><code>af74840</code></a> fix: harden cookie domain, path, and unparsed attribute validation</li>
<li><a href="https://github.com/nodejs/undici/commit/551138cbc1742c92242a68216167761075e8a82c"><code>551138c</code></a> Bumped v6.27.0 (<a href="https://redirect.github.com/nodejs/undici/issues/5431">#5431</a>)</li>
<li><a href="https://github.com/nodejs/undici/commit/b7f252e7c0841418fb9d95cd297bdd9fad9d2a53"><code>b7f252e</code></a> Backport WebSocket maxPayloadSize fixes to v7.x (<a href="https://redirect.github.com/nodejs/undici/issues/5423">#5423</a>) (<a href="https://redirect.github.com/nodejs/undici/issues/5428">#5428</a>)</li>
<li><a href="https://github.com/nodejs/undici/commit/25efa447997f74d5881edd144525c3fd7db945a4"><code>25efa44</code></a> fix(cookies): preserve values and parse SameSite strictly</li>
<li>Additional commits viewable in <a href="https://github.com/nodejs/undici/compare/v6.23.0...v6.28.0">compare view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=undici&package-manager=npm_and_yarn&previous-version=6.23.0&new-version=6.28.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/react/react/network/alerts).

</details>