Investigation: MSVC C1202 and rfl complexity

When rfl reflects a struct S, it builds an rfl::Literal<f1, f2, …, fN> where the fi are the effective field names of S. For a plain struct, "effective" means the struct's own direct fields. For a struct containing rfl::Flatten<Sub>, "effective" means the union of the parent's non-Flatten fields plus all of Sub's effective fields — the flattening is recursive.

no_duplicate_field_names then checks every pair (fi, fj) with i≠j for equality, producing an O(N²) instantiation graph of width proportional to N².

Key fact: rfl::Flatten does not reduce the parent Literal size. A parent struct with three rfl::Flatten members whose sub-structs have 5, 9, and 5 fields respectively will produce a parent Literal with 5+9+5 = 19 entries — identical to the original flat 19-field struct. The sub-structs are also reflected independently (producing smaller Literals), but the parent Literal is not reduced.

Understanding the mode of failure is essential for choosing the right fix:

ClientManager.cpp was split into focused per-function TUs (PRs #754, #757). This addressed Mode 1 failures by reducing context per TU. It is a maintenance burden but provided short-term relief.

Tasks: Raise MSVC constexpr limits (sprint 17)

Raised /constexpr:depth and /constexpr:steps to large values. Had no effect on C1202 (wrong category of limit). Reverted/superseded.

Task: Decompose trade into rfl::Flatten sub-structs (sprint 17) — PR #761

trade had 25 fields. Decomposed into 5 sub-structs (identity/parties/ classification/lifecycle/audit, max 7 fields each) composed via rfl::Flatten.

Result: C1202 on trade resolved. This worked because trade's C1202 was a Mode 1 failure — the 25-field parent Literal was not saturating the limit alone; it only fired in combination with other large types in the same TU. Reducing the accumulated instantiation context (by making each sub-struct available as a separate, smaller template instantiation) was sufficient.

What was NOT understood at the time: rfl::Flatten does NOT reduce the parent trade Literal — trade still has a 25-field effective Literal. The fix worked because trade was a Mode 1 case. Had trade been a Mode 2 case (firing alone in a clean TU), rfl::Flatten would not have helped.

Task: Investigate RFL complexity root cause (sprint 18) Story: Resolve RFL complexity issues (sprint 18)

Investigation identified rfl::AddTagsToVariants on trade_instrument (a variant of ~30 leaf types totalling 502 field names) as the primary driver of Clang failures. The Triple Isolation strategy was implemented: TU split + two-phase parse + global -fbracket-depth=1024.

swaption_instr_outer was introduced as a surrogate struct to isolate heavy rfl instantiation from caller TUs. This is a correct pattern for Mode 1.

Task: Fix C1202 in ClientManagerExportPortfolio.cpp (task 9, sprint 19) — PR #1031

swap_leg has 19 fields. After PR #1010 isolated export_portfolio_response into ClientManagerExportPortfolio.cpp, MSVC C1202 fired at step 1140/4939 (early in the build, clean TU) — a Mode 2 failure.

Following the sprint 17 precedent, rfl::Flatten was applied: swap_leg was split into swap_leg_identity (5), swap_leg_terms (9), swap_leg_audit (5) composed via rfl::Flatten.

Result: C1202 persisted. The Windows CI error (step 1140/4939) after PR #1031 shows the identical 19-field Literal:

rfl::Literal<"version","tenant_id","id","instrument_id","leg_number",
"leg_type_code","day_count_fraction_code","business_day_convention_code",
"payment_frequency_code","floating_index_code","fixed_rate","spread",
"notional","currency","modified_by","performed_by","change_reason_code",
"change_commentary","recorded_at">

Why it failed: swap_leg is a Mode 2 case. Its 19-field effective Literal (which rfl::Flatten does not reduce) saturates the MSVC graph limit in a clean TU. The sprint 17 precedent was misapplied — that precedent was valid for Mode 1 but not Mode 2.

Side effects of task 9 that should be kept: The struct decomposition (swap_leg_identity / swap_leg_terms / swap_leg_audit) is architecturally sound and all callers have been updated. The decomposition should be retained; only the rfl::Flatten composition mechanism should change.

rfl::Flatten::get() is a library artefact with no domain meaning. Callers had to write sl.identity.get().leg_number when they meant sl.identity.leg_number. The nested struct approach is idiomatic C++; a reader unfamiliar with rfl can understand the code immediately.

Before:

auto& tm = sl.terms.get();
tm.leg_type_code = "Fixed";

After:

sl.terms.leg_type_code = "Fixed";

With rfl::Flatten, the struct definition itself depends on the rfl library header. Without it, swap_leg is a plain C++ struct that can be included in any TU with no rfl dependency. rfl is now only needed at serialisation boundaries, which is the correct layering.

A plain nested struct can be serialised by any library (rfl, nlohmann::json, Boost.JSON, protobuf, etc.) without structural modification. The flat rfl::Flatten form ties the struct layout to rfl's specific Flatten semantics.

The JSON changes from flat (19 top-level fields) to nested (3 top-level keys). This is a breaking wire-format change. The risk is low in ORE Studio because:

• The service and client are in the same repository, deployed together.
• swap_leg is an internal RPC type; no external consumers exist.
• The format change is consistent: the C++ nested structure now mirrors the JSON structure, eliminating a conceptual mismatch.

Recommendation: bump the export_portfolio_response protocol version to signal the format change clearly, and verify no persisted JSON (e.g. test fixtures or fixtures in the database) uses the flat format.

The C++ structure now accurately reflects the logical grouping:

• identity — who and when (version, tenant, id, instrument, leg number)
• terms — the economic terms (rate type, rate, notional, currency, indices)
• audit — the audit trail (who changed it, why, when)

This grouping makes the domain model self-documenting. It also aligns swap_leg with how trade was decomposed in sprint 17 (five sub-structs), creating a consistent pattern across the domain layer.

Both layouts are POD structs. Memory layout and cache behaviour are effectively identical. There is no runtime cost difference.

Flat 19-field structs are fragile: adding a 20th field (if the threshold is ~17-19) would silently re-trigger C1202. The nested layout makes adding fields safe: new fields go into the appropriate sub-struct (≤9 fields each) and C1202 cannot fire regardless of how many fields are added in future.

The exact field count at which MSVC fires C1202 in a clean TU is not precisely known. 9 fields is safe; 19 fields is not. Any new struct with more than ~12 fields should be evaluated before using rfl on it in isolation.

reflect-cpp Issue #350 was opened to request an upstream fix. If rfl eliminates the O(N²) compile-time uniqueness check (or provides a way to disable it per type), Mode 2 failures would disappear and the wire-format change would be unnecessary. Monitor this issue.

Any domain struct with >~12 fields that appears in an rfl serialisation chain in a relatively clean TU is at risk of Mode 2 C1202. A project-wide audit of field counts against the safety threshold would prevent future surprises.