Please provide time/memory measurements. This is only worth it if it leads to improvements.

Of course the LruCache refacoring is nice but should be separste from introducing the cache to new places.

Double-checked this before it gets reviewed, and it earned two additions.

Eviction is now actually exercised. The footprint numbers in the description came from a run with the shipped limits, where the type-alias cache only ever held two entries - so its eviction path was never touched. Re-ran the differential with the limits turned down, and with them at 0:

The second row is the one that matters for nameScopeMapMemoryCacheCountMax: 0: 237 misses on both sides. Had I passed the 0 straight through as "no limit", this branch would have shown far fewer misses, so that mapping is measured rather than argued. The type-alias eviction I forced separately on a fixture of 12 classes with local @phpstan-type aliases at resolvedLocalTypeAliasesCountMax: 1 - 12 misses and identical output on both sides.

Second commit: the limits are no longer properties. All four - including CachedParser::$cachedSourceBytesMax from #5928 - are read only where the LruCache is constructed, so keeping them promoted left per-instance state nobody reads and implied the classes consult them later. They are plain constructor parameters now.

Also checked and found nothing: no reference to the replaced properties survives anywhere in src/ or tests/, and the bounds are equivalent rather than off by one - the old code inserted and then evicted while over the limit, LruCache evicts before inserting, and both settle at exactly the configured maximum.

CI: the three reds are the two Symplify integration jobs (composer 404 on the TomasVotruba/ecs zipball) and the Benchmark job, whose only failing case is bug-11283.php, already failing on 2.2.x itself - it showed +136% there earlier today against +72% here. Full suite 21334, self-analysis and phpcs clean.

To be clear on the intent: this adds no caching and was not aimed at performance. It re-uses the LruCache from #5928 in the three places that were hand-rolling the same touch-and-evict logic, which is what @staabm asked for in #5928 (comment). Four hand-rolled LRUs become one with a unit test, net -23 lines.

Measurements anyway, base 8e60b1adc against bc70f8e53, symfony 6.4 + doctrine vendor tree (3862 files, level 5), 5 interleaved rounds, medians:

The time deltas sit inside spreads several times their size, so read it as unchanged - no gain, no regression. The hit/miss footprint is identical too (1168 name-scope map misses, 910 member-cache evictions on both sides), which is the point: same caches, same behaviour, less code.

If that cleanup is not worth carrying the abstraction, close it and I will not argue - the class stays in from #5928 either way.

Two side notes. The second commit (the limits stop being properties, since they are only read where the cache is constructed) is a separate concern - happy to split it out. And FileTypeMapper::$resolvedPhpDocBlockCache, which I left alone because it evicts in insertion order rather than by use, is the one place where switching to LruCache does change something measurable: PHPDoc resolutions 12480 -> 12217 (-2.1%) on that corpus, identical output. Separate PR if you want it.

Thank you!