Bug report
Full Disclosure: This report is AI generated, but represents a real problem that I have. On Windows 10, after running phpstan analyse -vv consecutively I compare the resultCache.php files and they appear exactly the same excluding lastFullAnalysisTime which is normal I think. Nevertheless, I always get - "Result cache not used because the metadata do not match: analysedPaths, executedFilesHashes" where both sections contain PHAR files.
PHPStan result cache is not reused on Windows starting with 2.2.9.
Reproduction
Environment:
- Windows
- PHPStan 2.2.9–2.2.12
- PHPStan PHAR invoked through an absolute path
Two consecutive unchanged runs:
phpstan analyse -vv
phpstan analyse -vv
The second run reports:
Result cache will not be used.
Reason: Result cache not used because the metadata do not match: scannedFiles, executedFilesHashes
PHPStan 2.2.8 reuses the cache correctly with the same project and configuration.
The cached executedFilesHashes contains entries such as:
'phar://phpstan.phar/stubs/runtime/Attribute85.php' => '...',
'phar://phpstan.phar/stubs/runtime/ReflectionAttribute.php' => '...',
The apparent problem is the PHAR path round-trip on Windows.
A cached path such as:
phar://phpstan.phar/stubs/runtime/Attribute85.php
is restored as:
phar://C:\var\php\phpstan.phar\stubs\runtime\Attribute85.php
while the currently executed file is represented as:
phar://C:/var/php/phpstan.phar/stubs/runtime/Attribute85.php
These strings do not compare equal.
Minimal reproduction of the path difference:
echo DIRECTORY_SEPARATOR;
// \
$cached = 'phar://phpstan.phar/stubs/runtime/Attribute85.php';
// equivalent restored form:
$restored = 'phar://C:\var\php\phpstan.phar\stubs\runtime\Attribute85.php';
$current = 'phar://C:/var/php/phpstan.phar/stubs/runtime/Attribute85.php';
var_dump($restored === $current);
// false
This appears related to the result-cache relative-path changes introduced in 2.2.9, where stream-wrapper paths are split, the filesystem part is normalized using the platform separator, and the scheme is then reattached.
For phar:// paths, the inner path should presumably continue using / even on Windows.
The regression starts exactly at:
2.2.8 -> cache reused
2.2.9 -> cache invalidated every run
Code snippet that reproduces the problem
No response
Expected output
Result cache restored. 0 files will be reanalysed.
Did PHPStan help you today? Did it make you happy in any way?
I use PHPStan all the time and it's really wonderful.
Bug report
Full Disclosure: This report is AI generated, but represents a real problem that I have. On Windows 10, after running
phpstan analyse -vvconsecutively I compare theresultCache.phpfiles and they appear exactly the same excludinglastFullAnalysisTimewhich is normal I think. Nevertheless, I always get - "Result cache not used because the metadata do not match: analysedPaths, executedFilesHashes" where both sections contain PHAR files.PHPStan result cache is not reused on Windows starting with 2.2.9.
Reproduction
Environment:
Two consecutive unchanged runs:
The second run reports:
PHPStan 2.2.8 reuses the cache correctly with the same project and configuration.
The cached
executedFilesHashescontains entries such as:The apparent problem is the PHAR path round-trip on Windows.
A cached path such as:
is restored as:
while the currently executed file is represented as:
These strings do not compare equal.
Minimal reproduction of the path difference:
This appears related to the result-cache relative-path changes introduced in 2.2.9, where stream-wrapper paths are split, the filesystem part is normalized using the platform separator, and the scheme is then reattached.
For
phar://paths, the inner path should presumably continue using/even on Windows.The regression starts exactly at:
Code snippet that reproduces the problem
No response
Expected output
Result cache restored. 0 files will be reanalysed.
Did PHPStan help you today? Did it make you happy in any way?
I use PHPStan all the time and it's really wonderful.