Story: Resolve RFL complexity issues

Table of Contents

This page documents a story in Sprint 18.

Goal

Permanently resolve the compilation failures in ores.qt.api on Windows (MSVC C1202) and Linux (Clang bracket depth) by re-applying the structural isolation strategy (TU splits and two-phase parsing) and increasing global compiler limits.

Status

Field Value
State DONE
Parent sprint Sprint 18
Now Completed 2026-05-24.
Waiting on Nothing.
Next None.
Last touched 2026-05-24

Acceptance

  • projects/ores.qt.api/src/ClientManagerTrades.cpp compiles successfully on Clang (Linux) and MSVC (Windows).
  • Structural isolation (TU split for getTradeDetail) is implemented.
  • Two-phase parsing for get_trade_detail_response is restored.
  • Global compiler flags for Clang (-fbracket-depth) are increased.
  • No regressions in trade listing or detail retrieval functionality.

Tasks

Task State Start End Description
Task: Investigate RFL complexity root cause DONE 2026-05-23 2026-05-23 Analyze the root cause of Clang and MSVC compilation failures related to reflect-cpp complexity.
Task: Implement triple isolation for RFL complexity DONE 2026-05-23 2026-05-24 Apply the TU split, two-phase parse, and increased Clang limits to resolve compilation failures.

Decisions

  • Structural Isolation over Limit Hacking: Previous attempts to solve C1202 purely via /constexpr limit increases failed because they did not address the hard instantiation depth limit. We will prioritize TU splits and two-phase parsing.
  • Upstream Collaboration: We have opened reflect-cpp issue #350 to advocate for an O(N) field uniqueness check.

Out of scope

  • Refactoring the entire domain model to reduce field counts (this is a multi-sprint architectural change).
  • Migrating away from reflect-cpp (it is deeply integrated into the codebase).

See also

Emacs 29.1 (Org mode 9.6.6)