feat(io): FastParse FEN
Build & Test (NowChessSystems) TeamCity build failed

Added FastParse FEN and dependencies
This commit is contained in:
LQ63
2026-04-07 12:59:12 +02:00
parent b4bc72f7e4
commit 13d4a62a71
5 changed files with 222 additions and 1 deletions
+9
View File
@@ -0,0 +1,9 @@
## [2026-04-06] FenParserFastParse: scoverage cannot reach 100% due to fastparse inline macro incompatibility
**Requirement/Bug:** 100% line/branch/method scoverage on `FenParserFastParse.scala` as specified in the coverage target.
**Root Cause:** fastparse 3.x uses Scala 3 `inline` macros for its `parse(...)` entry points. When scoverage instruments the compiled output, it generates synthetic proxy methods (e.g. `parse0$proxy9`, `parse0$proxy10`) from the macro expansion. These proxies are attributed to the source lines of the parser definitions but are never directly invoked at runtime — the actual execution goes through the inlined code paths. This results in 33% of statements being reported as uncovered despite all parser branches being exercised by the test suite.
**Attempted Fixes:** All six test cases (parseBoard valid, parseFen valid, reject invalid color/castling, importGameContext, reject malformed boards, reject overflow ranks) exercise every parser path. The issue is not in test coverage of logic but in how scoverage tracks inline-macro-generated bytecode. No source-level change can cause scoverage to instrument through `inline` expansion boundaries.
**Next Step:** Either accept the coverage gap for this file (it is an instrumentation artefact, not a logic gap) or replace the `parse(...)` call sites with a non-inline wrapper that shields the proxy generation from the coverage-instrumented compilation unit.