Don't reuse cleaned ASTs for analysed files

[binaryfire]

PathRoutingParser can't choose the parser for analysed files until the analysed file list is set. If an eagerly created extension uses ReflectionProvider in its constructor, CachedParser can store a cleaned AST and return it later during analysis. The affected extension types are property and method class reflection extensions, dynamic function, method, and static method return type extensions, and function, method, and static method type-specifying extensions. Rules and collectors are created after the analysed file list is set, so they can't trigger it.

This PR tracks whether cached ASTs contain the full file representation and upgrades cleaned entries when an analysed file needs one. It adds unit coverage for both cache entry paths and an e2e case for early reflection. In a cold Hypervel analysis, the new per-process route memo reached at most 1,787 entries.

[ondrejmirtes]

Please reproduce the problem as well with e2e test.

With what kind of extension this happens?

[binaryfire]

This can happen with extensions from the collections PHPStan loads while creating TypeSpecifier: property and method class reflection extensions, dynamic function, method, and static method return type extensions, and function, method, and static method type-specifying extensions. If one uses ReflectionProvider in its constructor to inspect a class that's also being analysed, it can trigger parsing before the analysed file list is set. Rules and collectors are created later, so they can't trigger it.

I've added a minimal e2e case using a MethodsClassReflectionExtension. On the old code, the cold run reports return.missing because analysis reuses the earlier AST without the method body. The updated code upgrades that entry and the analysis passes.

[ondrejmirtes]

Doing work in constructor is a bad idea for many reasons. Did you personally encounter or find an extension that does this on GitHub?

[binaryfire]

You’re right - the extension was Hypervel’s ForwardedFluentMethodExtension, and it was reflecting eagerly in its constructor. I’ve changed it to defer that lookup until method resolution, so I’m closing this PR. Thanks for pointing me in the right direction.

[staabm]

Please show how the fix look like.. maybe we can improve some phpstan rules to raise awareness

[binaryfire]

Sure. Here you go: https://github.com/hypervel/components/pull/546/changes

The pin to 2.2.9 is unrelated to this PR. I'm having issues with 2.2.10 stopping early when analysing with multiple forked workers. Some jobs never finish. I've pinned to 2.2.9 because the same analysis completes reliably there. Will dig into that more when I have time.

[staabm]

Some jobs never finish. I've pinned to 2.2.9 because the same analysis completes reliably there. Will dig into that more when I have time.

Likely fixed in todays 2.2.11