[tstokes8040]

✅ Committed in r64336 (d655404).

---

PHPStan infers current_user_can() and WP_Filesystem_Base::chmod() as pure, so it remembers what each returned and reuses that value at a later call in the same scope. Both can legitimately answer differently the second time:

Function	Why a second call can differ
current_user_can()	Reads the current user and applies the user_has_cap filter, so a plugin hooked in between can change the answer
WP_Filesystem_Base::chmod()	Changes the permissions that a following is_writable() reports

The clearest case is wp-admin/link-manager.php. Line 11 bails out unless the user has manage_links, and line 91 checks the same capability again after admin-header.php has been required and its hooks have fired. PHPStan carried the line 11 answer forward and reported the line 91 guard as dead.

Note

This PR originally also annotated WP_HTML_Processor::next_token(). That annotation landed separately in r64335 via #14037, so trunk has been merged in and the PR now carries only the two annotations above.

Annotating the mutation, not the accessor

PHPStan's tips name is_writable() as a candidate. That is a read-only accessor and annotating it would be inaccurate. What actually invalidates a remembered value is the mutating call sitting between the two reads, so the annotation belongs there: in WP_Upgrader::install_package() it is the chmod() between two is_writable() calls.

WP_Filesystem_Base::copy() was annotated at first and then removed after re-running the analysis with and without it produced identical results; chmod() alone covers the copy_dir() case. WP_User::has_cap(), where the user_has_cap filter is actually applied, was also tried and cleared nothing, so the annotation sits on current_user_can() itself.

Impact

13 errors resolved across five identifiers, with no new error of any identifier anywhere in the codebase:

Baseline	Before	After
booleanNot.alwaysFalse	7	2
booleanNot.alwaysTrue	7	4
booleanAnd.leftAlwaysTrue	3	2
if.alwaysTrue	6	3
ternary.alwaysTrue	2	1

The if.alwaysTrue errors are in wp-admin/my-sites.php and wp-admin/upload.php (×2), and the ternary.alwaysTrue one is in wp-admin/theme-install.php.

The baselines are generated, not hand-edited. No baseline reaches zero here, so none is deleted and phpstan.neon.dist is unchanged.

Testing instructions

1. npm run typecheck:php on trunk reports [OK] No errors, because the occurrences are baselined.
2. With this branch applied, npm run typecheck:php reports [OK] No errors with the baselines regenerated (composer phpstan:baselines).
3. To confirm the change is surgical, run the analysis with all baselines suppressed before and after and diff the results, comparing on file plus message rather than on line number, since added docblock lines shift every line below them. Compared correctly, exactly 13 errors disappear and none appears.

Documentation-only change; no runtime behavior is affected.

Related: #13057 annotates WP_HTML_Tag_Processor::parse_next_tag() for the same reason (committed in r63301), and #13071 clears a different cluster of the same boolean baselines.

Trac ticket: https://core.trac.wordpress.org/ticket/65817

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: grouping the remaining boolean PHPStan baselines by root cause, identifying this cluster, testing which annotation placements were load-bearing, measuring the before/after error diff across the whole codebase, regenerating the baselines, and drafting this description. The change itself and the verification runs were reviewed and confirmed by me in a local development environment.

The trunk merge after r64335, the baseline regeneration, and this updated description were done with Claude Code (Claude Opus 5.5).

Count of removed errors: 13

[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 tstokes8040, westonruter.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[westonruter]

🤖 Comment by Claude Opus 5.5

The @phpstan-impure annotation on WP_HTML_Processor::next_token() has landed in r64335 via #14037, which also removed the booleanOr.alwaysTrue, booleanNot.alwaysTrue and deadCode.unreachable baseline entries for class-wp-block.php. The analysis in this PR of the next_token() loop between the two is_tag_closer() calls in WP_Block was the same root cause, and it is credited in that changeset.

This PR will now conflict with trunk. The remaining annotations on current_user_can() and WP_Filesystem_Base::chmod() are still outstanding, so a rebase dropping the class-wp-html-processor.php change and regenerating the baselines would leave just those two.