Build/Test Tools: Apply the PHPStan node visitors to every file parsed

[westonruter]

✅ Committed in r63462 (e0be8ea).

---

Follow-up to #13233 (r63420, f3cc113), which taught PHPStan to read hash notation.

HashNotationVisitor is tagged phpstan.parser.richParserNodeVisitor, and a visitor tagged that way runs in PHPStan's RichParser. PathRoutingParser sends a file to that parser only when it is one of the files being analyzed. A file merely read so that something it declares can be reflected goes to the simple parser instead, where the visitors never run.

PHPStan can route that way because its own two parsers agree about everything reflection exposes. The simple one is wrapped in a CleaningParser, whose CleaningVisitor empties function, method and closure bodies and touches nothing else, so docblocks and signatures come out of either parser identically. What is reflected out of a file does not depend on whether that file was analyzed — which is what makes it correct for PHPStan to key its per-file reflection cache on the file's contents alone.

HashNotationVisitor breaks that agreement. It rewrites @param, @return and @var docblocks, which are exactly what reflection exposes.

What that costs today

Analyzing a subset of the tree reports against types the visitor would have replaced, wherever one crosses a file boundary. WP_Widget_Media::get_l10n_defaults() assigns the return of _n_noop(), whose @return is hash notation, so it is such a boundary:

# phpstan analyse src/wp-includes/widgets/class-wp-widget-media.php
Static property WP_Widget_Media::$l10n_defaults (array<string>) does not accept
array<string, array|string>.

# phpstan analyse   (whole configured tree)
Static property WP_Widget_Media::$l10n_defaults (array<string>) does not accept
array<string, array<int|string, string|null>|string>.

The narrowed run is the wrong one. It is also the shape most tooling runs in: an editor analyzing the file being typed in, or a run scoped to a diff. Both under-report, against a type wider than the documentation describes, and can equally report errors a full run does not.

The reading is then stored in the shared cache, so the next full run restores it — which is how this surfaced. Core-65817 has a companion PR, #13395, isolating baseline generation from that. This addresses the cause rather than that one consequence, and the two are independent.

The change

Have the simple parser wrap the rich one. Every parse then rewrites the same docblocks, the cleaning still happens on top of it, and the reflection cache is keyed on contents correctly again.

This redefines currentPhpVersionSimpleParser in terms of currentPhpVersionRichParser, both PHPStan's own service names from its conf/parsers.neon, and neither a documented extension point. Should a release rename either, the definition stops being wired into anything and today's behavior returns silently. That tradeoff is recorded beside the definition together with what to check, and it is the reason the comment there is as long as it is. Worth a reviewer's opinion on whether it is acceptable — the alternative is leaving subset analysis wrong.

Results are unchanged

• Analyzing the whole configured tree before and after reports the same 1544 errors, with no textual difference between the two outputs.
• Every baseline still matches, with reportUnmatchedIgnoredErrors: true.
• Regenerating every baseline leaves tests/phpstan/baselines byte-identical.
• Builds and analyzes at level 10 with bleedingEdge, and completes at the 2G limit CI uses.

What it costs

Parsing that a subset run used to avoid is now work it does, so a cold cache pays for it. Three runs per cell, spread within each under 0.1s:

Target	Cache	Before	After	Delta
One file	cold	3.39 / 3.42 / 3.50	3.90 / 3.93 / 3.96	+0.5s (+14%)
One file	warm	2.23 / 2.23 / 2.25	2.11 / 2.12 / 2.24	none
src/wp-includes/widgets (14 files)	cold	5.19 / 5.21 / 5.34	6.53 / 6.53 / 6.54	+1.3s (+24%)
src/wp-includes/widgets	warm	1.50 / 1.51 / 1.60	1.53 / 1.53 / 1.53	none
Whole tree	cold	29.0s	29.6s	+0.6s (+2%)

A warm cache reads the same stored result either way, so it is unchanged — and that is the case an editor and a diff-scoped run are in after their first analysis. src/wp-includes/widgets is the worst ratio because it analyzes fourteen small files while reflecting most of wp-includes: the denominator is fixed and the numerator barely grows.

Memory moves from 174.5 MB to 176.5 MB. The cache on disk is the same size, 8.5 MB either way, because CleaningParser still wraps the result and the stored trees are stripped exactly as before.

CI analyzes the whole tree, so it pays the 2%, and only on a cold cache — which this change causes once anyway, its cache being keyed on the files in tests/phpstan.

Trac ticket: Core-65817

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Tracing the behavior through PHPStan's parser routing, and drafting the change, its comment and the benchmarks. Every claim above was measured rather than reasoned: the differing messages were reproduced from the two run shapes, the full-run outputs diffed, and each timing repeated three times. Reviewed by me.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01EdFn9fuiUhJMXzacuhmdGJ

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props westonruter.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[swissspidy]

Sounds plausible 👍