Merge deeply nested objects without recursing per nesting level

[nlohmann]

What & why

merge_patch() and update(j, true) merge a nested object by calling themselves on it, once per nesting level. A value nested deeply enough terminates the process with SIGSEGV: 50,000 levels of objects on an 8 MiB stack. parse() accepts such values without complaint. Reported in #5393 (merge_patch) and #5545 (update).

Part of the same series as #5546, see the table there.

The change

Bound the descent the same way dump() does:

• The recursion now carries the nesting level. update() keeps its public checks and hands the member loop to a private update_members(), which calls itself for nested objects. merge_patch() does the same through apply_merge_patch().
• Once detail::recursion_depth_limit() (128, shared with the other operations) levels have been entered, update_members_iteratively() and merge_patch_iteratively() finish the merge on an explicit stack.
• The iterative versions still merge a nested object completely before the next member, in the same order. So the results, including the parents JSON_DIAGNOSTICS reports paths from, are unchanged. That matters for ordered_json, whose inserts move sibling members.

Values nested less deeply than the bound run the same code as before, so the common case doesn't pay for a stack. A first, fully iterative version cost 10–14% on ordinary merges, which is why it bounds the descent instead.

Verification

• Identical results: a differential against develop compares update(j, true), update(j) and merge_patch() on 4,000 random pairs each, plus explicit chains crossing the bound (120–131, 200, 300 levels). Results are identical for json and ordered_json, and under JSON_DIAGNOSTICS for json, where every node's diagnostic path is compared: 82,137 paths, the deepest about 300 levels. ordered_json under JSON_DIAGNOSTICS hits a pre-existing parent-pointer assertion in merge_patch() on develop too (minimal case below); it is unaffected by this change.
• Deep values: 1,000,000 levels merge fine on a 1 MiB stack, with and without JSON_DIAGNOSTICS; develop crashes at 100,000.
• Speed: unchanged: update(j), update(j, true) and merge_patch() on a small nested document measure the same as develop (clang -O3, three repetitions).
• Tests:
  • Every depth up to 300 is checked against recursive reference implementations of both operations.
  • The diagnostic paths are checked past the bound, and objects nested 100,000 levels deep are merged.
  • A mutant whose iterative update never merges fails 515 assertions; one whose iterative merge_patch doesn't erase fails 339.
• make amalgamate + make check-amalgamation; no new clang-tidy or -Weverything findings.

Pre-existing, for the record (same on develop): with JSON_DIAGNOSTICS, ordered_json::parse(R"({"a":{"c":{"d":{}}}})").merge_patch(ordered_json::parse(R"({"a":{"c":{"c":"s","d":null},"e":"s"}})")) fails the parent assertion in assert_invariant. To be investigated separately.

Public API impact

No breaking changes. The public signatures of update() and merge_patch() are unchanged. The recursive worker behind merge_patch() has its own name rather than being a private overload, so &basic_json::merge_patch stays unambiguous.

---

• The changes are described in detail, both the what and why.
• If applicable, an existing issue is referenced. (Stack overflow in diff(), merge_patch(), and flatten() due to unbounded recursion #5393, Stack overflow in std::hash<basic_json> and update(j, true) on deeply nested values #5545)
• The Code coverage remained at 100%. A test case for every new line of code.
• If applicable, the documentation is updated. (nothing documents the recursion)
• The source code is amalgamated by running make amalgamate.

🤖 Generated with Claude Code