Relative paths in scanFiles lead to cache invalidation #15125

Bug report

We have the following entry in our phpstan.neon:

parameters:
    scanFiles:
        - %rootDir%/../../../vendor/autoload.php

Ignoring the fact that this is a useless entry, it leads to cache invalidation:

$ vendor/bin/phpstan analyse -vvv
Result cache not used because the metadata do not match: scannedFiles, composerInstalled

Using paths without .. works cleanly:

parameters:
    scanFiles:
        - vendor/autoload.php

$ vendor/bin/phpstan analyse -vvv --memory-limit 1G
Composer metadata changed but no package versions changed; keeping the result cache.

Coding-agent (unverified) claims:

The new ResultCachePathTransformer relativizes paths on save and absolutizes them on load. The round trip is lossy: absolutizePath() runs normalizePath(), but the values PHPStan freshly computes each run are not normalized. So restored ≠ recomputed, forever.

Proven directly against your vendor tree:

scanFiles (%rootDir%/../../../vendor/autoload.php)
computed now : …/api/vendor/phpstan/phpstan/../../../vendor/autoload.php
stored as : ../../../vendor/autoload.php
restored as : …/api/vendor/autoload.php ← ".." collapsed
equal? : MISMATCH

Code snippet that reproduces the problem

parameters:
    scanFiles:
        - %rootDir%/../../../vendor/autoload.php

Expected output

No cache invalidation without changes

Did PHPStan help you today? Did it make you happy in any way?

Just upgraded to 2.2.6 from 2.1 and I'm very happy about the new sealed and unsealed arrays. 👍