[0.88] Bump Hermes to 260318099.0.4

[fabriziocucci]

Target Branch

0.88

Link to commit or PR to be picked

Hermes release 260318099.0.4, to be cut from 260318099.0.0-stable and pinned into 0.88-stable.

Description

0.88 pins 260318099.0.3 today. One fix and one re-land have landed on the Hermes stable branch beyond the hermes-v260318099.0.3 tag and neither reaches the release until a new tag is cut and RN is bumped to it.

The fix

892dc627d Avoid reserve() in ConsecutiveStringStorage (D121660203, grafts D121478636)

Lazy compilation appends to the string storage every time a newly compiled function adds strings. ConsecutiveStringStorage::appendStorage called reserve() before copying and on libc++ reserve() sizes to exactly the requested capacity rather than growing geometrically, so repeated appends were quadratic. Adds a lazy-string-growth micro-benchmark.

The re-land, which needs a decision before pinning

ace586d90 Back out "Back out D116775223 (VariableScope rescan pick)" (D120733339)

This is not a fix. It is a back-out of a back-out, so its effect is to put a previously reverted change back into the release. The chain:

• D116775223 landed the original VariableScope rescan pick
• D118959426 backed it out for a SIGSEGV in AR effects on Messenger Android
• D120733339 re-lands it

Its stated justification is that the crash could not be reproduced and that another fix may have already covered it. That other fix could not be located on 260318099.0.0-stable or on static_h, so the claim is unverified from the branches alone.

It is also a byte-exact restoration rather than a reworked version. All five touched files (IR.h, IR.cpp, IRBuilder.cpp, Utils.cpp, VariableTest.cpp) match their content at the original pick and differ from hermes-v260318099.0.3.

This was foreseen. #1413 recorded that static_h still carried the change and that it was the source the next stable sync would pull from, so its return was expected rather than accidental.

Also in the cut, no behaviour change

Commit	Diff
e3371863e	D120562343	Doc comment on IEventLoopControl::scheduleTask
d412d3bd8	D121160587	JSIDynamicTest.cpp, test only
0ad1d016d	D121664017	Version bump to .0.4 (facebook/hermes#2197)

The version bump is listed because it is load-bearing rather than incidental. RN Build Static Hermes has no version input: getMainVersion() reads npm/hermes-compiler/package.json verbatim, so the file has to name .0.4 before the workflow can cut it. It read 260318099.0.3 until #2197 landed, which meant a dispatch would have re-cut an already-published version. The stable ref is protected and rejects direct pushes, so the bump had to go through a PR.

Steps

1. Cut hermes-v260318099.0.4 with release-type=release and update-latest-v1=true. The latest-v1 tag points at .0.3 today and 26xxxx is the newest line, so it should move.
2. Verify the tag actually contains 892dc627d and ace586d90 before pinning. hermes-v260318099.0.2 was tagged eight hours before a crash fix was backed out and shipped the bad version anyway, so tag contents get checked rather than assumed.
3. Bump packages/react-native/sdks/hermes-engine/version.properties and packages/react-native/package.json on 0.88-stable. Both read 260318099.0.3 today. Do not hand-commit packages/rn-tester/Podfile.lock; the publish workflow regenerates it.

Prior record

#1413 covers the .0.3 cut and the JSI implementation batch that went into it.

[github-actions]

Thank you for opening a new React Native Pick Request.

These are the criteria we follow when accepting or rejecting a code change into a React Native release branch (source).

If your Pick Request does not satisfy the criteria below, please close it as it will not be considered.

✅ Which Pick Requests we accept

1. ✅ Fixes for regressions to core APIs. Examples:
   • A core component is behaving differently between versions 0.X and 0.X-1
   • The TurboModule.getEnforcing function is throwing an unexpected assertion error.
2. ✅ Fixes to bugs in core React Native. Examples:
   • Breakpoints in React Native DevTools not working correctly in the debugger
   • Fast Refresh not working as expected
   • Metro bundler not starting properly or ignoring the configuration file
   • Buttons that are not clickable
3. ✅ Fixes to APIs used by third-party libraries and out-of-tree platforms. Examples:
   • An API used by react-native-macos is not behaving as expected or is regressing
4. ✅ Bump of patch version of dependencies. Example:
   • Bump Gradle from 8.11.0 to 8.11.1
5. ✅ Fixes for low/high severity security vulnerabilities. Example:
   • Bump Gradle from 8.11.0 to 8.12.0 if there is a security vulnerability in 8.11 and no 8.11.x version contains the same fix.
6. ✅ Fixes and reverts of accidental breaking changes. Example:
   • Reverting or fix-forwarding a Kotlin migration of a file (e.g. ReactRootView.java) if it is causing a breaking change for the React Native ecosystem.
7. ✅ Performance improvements. Examples:
   • Fixing unnecessary re-renders in FlatList.
8. ✅ Any Pick Request if the release is still in RC0 (after RC1, the previously listed criteria apply)

❌ Which Pick Requests we don't accept

9. ❌ Any Pick Request that introduces a breaking change after RC1. Example:
   • A bugfix that contains a refactoring, resulting in changes to the public API of a class
10. ❌ Any Pick Request that introduces a new feature after RC1. Example:
    • A commit that introduces a new API or a specific feature for a component.
11. ❌ Bump of major or minor version of dependencies. Examples:
    • Bump Gradle from 8.11.0 to 8.12.0
    • Bump Gradle from 8.11.0 to 9.0.0
12. ❌ Bump of a dependency to a pre-release version. Example:
    • Bump Gradle from 8.11.0 to 8.11.1-beta.1
13. ❌ Any Pick Request that introduces changes to the React Native testing infrastructure after RC1. Examples:
    • Changes to GitHub Actions workflows to optimize them, even if they are on main.
    • Changes to the logic used to publish packages to NPM or Maven Central
14. ❌ Pick Request composed of multiple commits that have several merge conflicts.
    • If your Pick Request is too complex to apply to the release branch, it will be rejected.
15. ❌ Any non-critical improvement that landed on main.
    • These will generally ship in the following version unless they fit one of the criteria above.
16. ❌ Any Pick Request considered a "nice to have".
    • Even one-line changes carry a risk of destabilizing and further delaying the release.

ℹ️ What makes for a good Pick Request

In order for your Pick Request to be considered, please do the following:

• ℹ️ Limit your Pick Request to one commit from main, or one PR against the release branch.
• ℹ️ Include a clear explanation of why your Pick Request should be considered, ideally referencing one of the criteria above.
• ℹ️ Target only one minor version of React Native (e.g. [0.76]). To have your Pick Request applied to more versions, please open separate Pick Requests.