fix(iOS): make jsinspector-modern tracing state types move-only for Swift C++ interop

[chrfalch]

Summary

The nightly-tests job [ios] react-native-unistyles fails on Xcode 26.3 with:

error: no matching function for call to '__construct_at'
note: in instantiation of member function 'std::vector<...RuntimeSamplingProfile>::vector' requested here
note: in implicit copy constructor for 'facebook::react::jsinspector_modern::tracing::TraceRecordingState' first required here

while compiling the Swift files of the Unistyles pod. The same failure hits any library built with Swift C++ interop (-cxx-interoperability-mode=default) — in practice, every Nitro-based library — against the prebuilt React Native core.

The error

TraceRecordingState and HostTracingProfile hold std::vectors of move-only types (RuntimeSamplingProfile and FrameTimingSequence explicitly delete their copy constructors). Here's the C++ subtlety: std::vector<T>'s copy constructor is declared for every T — it only becomes ill-formed when instantiated. So the implicit copy constructors of these two structs are not implicitly deleted; they exist as declared-but-broken constructors that hard-error the moment anything asks for a copy.

Why React Native compiles fine today

Nothing in RN ever asks. Every usage passes these types by reference; the single constructions move. A pure C++ (or ObjC++) build never instantiates the implicit copy constructors, so this code has always compiled — and always would, no matter how much C++ CI you throw at it. The defect is unobservable from within C++.

What fails, and why now

The prebuilt-core headers now ship as real clang modules. A Swift target with C++ interop imports them (directly or transitively — e.g. via a module member whose #ifdef __cplusplus body opens because interop builds modules with C++ enabled), and Swift's ClangImporter surfaces the C++ value types to Swift as copyable. When the consumer's generated interop code then uses such a type as a Swift value — for a Nitro-based library, the nitrogen-generated *_cxx.swift bridging does exactly this — the compiler synthesizes a copy of the type, instantiating the ill-formed implicit copy constructor. That is the "ask" that plain C++ never makes; on Xcode 26.3 it hard-errors the entire module import, killing every Swift file in the consumer. (Newer Swift toolchains treat such types as non-copyable instead of failing.)

Before the prebuilt-modules work there was no Swift-visible module containing these headers, so no interop consumer ever imported these types — which is why this surfaces now despite the C++ being unchanged.

We deliberately did not fix this by removing headers from the module maps: the guarded-C++-in-modules pattern is shared by ~30 legitimately modular headers and is benign in all but this one shape, and experiments showed the type is reachable through multiple independent module surfaces (removing one member just moved the error to the next path).

The fix

Declare the truth: make both types explicitly move-only.

TraceRecordingState(const TraceRecordingState &) = delete;
TraceRecordingState &operator=(const TraceRecordingState &) = delete;
TraceRecordingState(TraceRecordingState &&) = default;
TraceRecordingState &operator=(TraceRecordingState &&) = default;

With the copy constructor explicitly deleted, Swift's importer sees a non-copyable type and imports it as such instead of instantiating a broken copy. It is also simply more correct C++: these types were never copyable in practice, and the explicit deletion turns any future accidental copy into a clear compile error at the call site instead of a template backtrace.

Declaring special members makes HostTracingProfile a non-aggregate, so its one designated-initializer construction site (HostTargetTraceRecording.cpp) is converted to member-wise assignment.

A sweep of the affected header surface (std::vector/std::map/std::deque of move-only element types) found exactly these two types; a follow-up adds a headers-verify.js gate that imports the shipped modules under Swift C++ interop at prebuild time, so the next type with this shape fails RN's own CI instead of community nightlies.

Changelog:

[IOS] [FIXED] - Fix Swift C++-interop build failure (implicit copy constructor of TraceRecordingState/HostTracingProfile) for libraries using cxx interop with prebuilt React Native core

Test Plan

On a fresh RN-nightly app with stock react-native-unistyles@3.3.0 + react-native-nitro-modules, prebuilt core (RCT_USE_RN_DEP=1 RCT_USE_PREBUILT_RNCORE=1), Xcode 26.3:

• Red: stock headers reproduce the CI failure exactly (__construct_at → TraceRecordingState). Fixing only TraceRecordingState then surfaces the identical failure on HostTracingProfile — confirming the shape, not the type, is the bug.
• Green: with both headers fixed (stock module maps, nothing else changed): BUILD SUCCEEDED — zero __construct_at, zero shadowNodeFromValue, zero module errors.
• All RN-internal usages audited: references and moves only; no behavior change. Plain C++/ObjC++ compilation unaffected by construction.

🤖 Generated with Claude Code

[cipolleschi]

Thanks for fixing this

[meta-codesync]

@cipolleschi has imported this pull request. If you are a Meta employee, you can view this in D112802806.

[meta-codesync]

@cipolleschi merged this pull request in 3861118.