[TASK] Unit-test XmlFileLoader

[CybotTM]

Stacked on phpDocumentor#1345 — the base branch is fix/xml-version-string-coercion, not main. Review that one first; this adds only tests plus the one baseline entry they cannot coexist with.

Why

packages/guides-cli/tests/unit/ covers Command and Logger. XmlFileLoader has no unit test at all, so everything it does is reachable only through integration fixtures that render a whole site. Those prove what a reader sees. They do not cheaply reach the shapes an author is unlikely to write while the loader handles them explicitly: an attribute-less <project>, a file whose only child is <project>, a file with no <project>.

What it pins

Eight cases. The one that had no coverage anywhere: the single-quote stripping is backward compatibility for version and release, not a general unquoting rule — a title that really is quoted keeps its quotes. Widening that trim to every attribute would have gone unnoticed.

Each case was seen failing on a defect built for it: DOM reading removed, trim widened to every attribute, trim dropped, the direct-child search degraded to a subtree search, the project key withheld when empty, and the project key set unconditionally. Every case appears in at least one failure list — two of them appeared in none until the assertion was split, because ?? [] reported a missing project config and an empty one as the same state.

The baseline entry

Adding the test turned (8.4, lowest) red, with an error that is not an assertion:

PHPUnit\Runner\Baseline\FileDoesNotHaveLineException:
File "vendor/symfony/config/Loader/FileLoader.php" does not have line 0

Reproduced in a php:8.4-cli container after composer update --prefer-lowest, then narrowed by removing one baseline block at a time.

Declaring XmlFileLoader extends FileLoader makes PHP 8.4 raise the implicit-nullable deprecations of the inherited signatures while linking the class. Those are attributed to the parent file with no line, so PHPUnit reports the issue at line 0; the baseline then looks the file up, tries to read line 0 to hash it, and throws. It fires only where the baseline already knows that file, which is why the integration and functional suites — which load the same class — pass on the same cell.

A baseline entry pins a line number in third-party code. That is fragile across dependency resolutions on its own, and for this shape of issue no line number can ever match. Removing the block for this one file is the narrow fix; the deprecations it covered are now displayed, and failOnDeprecation="false" keeps them from failing anything. The other 39 vendor files in the baseline carry the same fragility — nothing observed justifies touching them here, and it is worth a separate look.

Verified

In the container on PHP 8.4 with the lowest set: unit 494, functional 117, integration 230, all green. On the locked set: PHPUnit 842, PHPStan level max, PHPCS and deptrac clean.

Assisted by claude-code:claude-opus-5 — Session

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud