while thinking about the idea suggested in phpstan/phpstan#7379 (comment) I came to this - in my eyes - even simpler solution to the problem.

instead of fiddling with all the different path-types involved we just use a separate resultCache-name per project-configuration file.

tbh the solutions seems to be to simple, so I think it might have some serious problems somewhere ;-).

(削除) in case we can proceed with this idea, I would check the current build errors and see how to actually test this change... (削除ここまで) at least the local testing on my project suggests that it is now using the result-cache where it didn't before.. so it seems to solve my problem at hand.

any feedback is welcome.

The $resultCacheName parameter of restore method shouldn't be misused for this, its usage is reserved only for PHPStan Pro purposes. It puts the result cache file in a subdirectory, I don't want to complicate it like that.

But hey - the logic you're doing here depends on $projectConfigArray and that is entirely available in restore() method too, so you can do the logic based on that there. A lot of useful values that can be used in the hash computation logic are already in the constructor/can be asked for there so I think this idea has wings.

adjusted per feedack and manually tested locally.

do we need a automatic test for the case? if so where and what to test (might be a bit hard because of random file-names involved)?

btw: in the docs there is no resultCachePath mentioned.. should it be added?

https://phpstan.org/config-reference#caching

The $resultCacheName parameter of restore method shouldn't be misused for this, its usage is reserved only for PHPStan Pro purposes. It puts the result cache file in a subdirectory, I don't want to complicate it like that.

But hey - the logic you're doing here depends on $projectConfigArray and that is entirely available in restore() method too, so you can do the logic based on that there. A lot of useful values that can be used in the hash computation logic are already in the constructor/can be asked for there so I think this idea has wings.

since checking exactly which hashes are generated is a bit too much IMO, I just verified phpstan will create result-cache files including some suffix (aka. the hash), which it did not do before this change.

the tmpDir case is already covered by an existing test which uses a tmpDir

this condition is covered by #1475

only thing I am not 100% sure: what needs to be here in this hash.

maybe just the $this->analysedPaths are already enough, since these are the absolute paths within the system..?