Match custom extension files to analysed paths by realpath so symlinked packages are not reported as outside analysed paths

[phpstan-bot]

Summary

When a custom PHPStan extension (rule, service, etc.) is provided by a package that is symlinked into vendor (for example a Composer path repository, a common mono-repo setup) and that package's source is included in the analysed paths, PHPStan still printed:

Result cache might not behave correctly.
You're using custom extension in your project config
but this extension is not part of analysed paths:

- PhpstanExt\Ext\MyRule

even though the extension is analysed. This is a false positive.

Changes

• src/Analyser/ResultCache/ResultCacheManager.php
  • getProjectExtensionFiles() now, when a service class file is not found directly in the analysed dependency graph and is not located under a vendor directory, tries to match it to an analysed file by realpath before treating it as outside of analysed paths.
  • New helper findAnalysedFileNameByRealpath() builds a lazy map from realpath(dependencyKey) => dependencyKey and resolves the reflection file name against it. The map is only built when needed, so non-symlinked projects are unaffected in behaviour and cost.
  • Added a ?array $analysedFileNamesByRealpath cache property, reset at the start of getProjectExtensionFiles().
• .github/workflows/e2e-tests.yml + e2e/result-cache-symlink/
  • New end-to-end test: an ext package is symlinked into the app's vendor through a Composer path repository and its src is added to the analysed paths. After modifying the rule, the run must not contain Result cache might not behave correctly.

Root cause

ReflectionClass::getFileName() returns the realpath of the class file (PHP resolves symlinks when including a file), whereas the analysed file/dependency keys are the paths as traversed from the configured paths — i.e. the symlinked path (vendor/.../src/MyRule.php). The two never matched, so getAllDependencies() returned nothing, the file wasn't under the app's vendor realpath (it resolves to somewhere outside, e.g. ../ext/src), and it was recorded as isAnalysed = false, triggering the warning.

The fix reconciles the two path forms by comparing realpaths: realpath(symlinkedAnalysedPath) === realpath(reflectionRealpath), so a symlinked-in extension that is actually analysed is correctly recognized. Genuinely non-analysed extensions (e.g. those living only in vendor or an unanalysed build/ dir) still fail the realpath lookup and are reported as before.

Test

• e2e/result-cache-symlink reproduces the reported setup with a Composer path-repository symlink and asserts the false-positive warning is gone. Verified it fails without the fix (the warning is printed) and passes with it.
• Probed the parallel path in the same method (extensions living in a real vendor dir, and extensions in an unanalysed dir such as e2e/result-cache-8's build/): both still correctly report the extension as outside analysed paths, because their realpath is not among the analysed files — no regression. e2e/result-cache-8 continues to assert the warning is shown.

Fixes phpstan/phpstan#14924