From b23ec1070205f906a00764fc9c86458b980c6efc Mon Sep 17 00:00:00 2001 From: LQ63 Date: Wed, 8 Apr 2026 09:28:46 +0200 Subject: [PATCH] feat(io): FastParse FEN Removed Unresolved doc --- docs/unresolved.md | 9 --------- 1 file changed, 9 deletions(-) delete mode 100644 docs/unresolved.md diff --git a/docs/unresolved.md b/docs/unresolved.md deleted file mode 100644 index 2519fe5..0000000 --- a/docs/unresolved.md +++ /dev/null @@ -1,9 +0,0 @@ -## [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.