Code Quality: Annotate WP_HTML_Tag_Processor::parse_next_tag() as impure

[tstokes8040]

✅ Committed in r63301 (3ecb392).

---

PHPStan infers WP_HTML_Tag_Processor::parse_next_tag() as pure, so it retains the STATE_READY narrowing assigned to $parser_state on line 981 across the call on line 989 — even though parse_next_tag() reassigns that property throughout its body. Every state comparison after the call is then decided at analysis time rather than at runtime.

The effects compound. The three !== comparisons on lines 1004–1006 each resolve to true, so both && nodes in that condition resolve to true, so the early return true on line 1008 is treated as unconditional. Everything from line 1012 to the end of base_class_next_token() is consequently analyzed as unreachable, which in turn makes skip_rawtext() and skip_script_data() appear uncalled and $skip_newline_at appear never assigned an int.

@phpstan-impure is the annotation PHPStan's own tip recommends here, and there is precedent for it in this very file: next_tag() already carries one.

Ten baselined errors across six identifiers are resolved:

Identifier	Removed
booleanAnd.alwaysTrue	2
notIdentical.alwaysTrue	3
identical.alwaysFalse	1
deadCode.unreachable	1
method.unused	2
property.unusedType	1

booleanAnd.alwaysTrue and property.unusedType reach zero, so as the baseline headers direct, both files are deleted along with their includes entries in phpstan.neon.dist. The baselines were regenerated with composer phpstan:baselines -- --identifier=..., not edited by hand.

Testing instructions

1. npm run typecheck:php on trunk reports [OK] No errors, because the occurrences are baselined.
2. Delete tests/phpstan/baselines/booleanAnd.alwaysTrue.neon and its includes entry, then re-run: PHPStan reports Result of && is always true. twice at src/wp-includes/html-api/class-wp-html-tag-processor.php:1004.
3. With this branch applied, npm run typecheck:php reports [OK] No errors across 1289 files with both baselines gone. composer lint is also clean for the modified file.
4. npm run test:php — 30865 tests, 4558966 assertions, 86 warnings, 44 skipped, and one failure: Tests_Script_Modules_WpScriptModules::test_default_script_module_files_exist, looking for src/wp-includes/js/dist/script-modules/a11y/index.js. That path is gitignored build output that is unbuilt in my checkout, and the test fails identically on unmodified trunk, so it is unrelated to this change. npm run test:php -- --group html-api passes 1714 tests, 6107 assertions, 0 failures.

Documentation-only change; no runtime behaviour is affected.

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: locating the occurrence via the PHPStan booleanAnd.alwaysTrue baseline, diagnosing the purity-inference cause and its knock-on effects, regenerating the baselines, and drafting this description. The change itself and the verification against the full PHPStan, PHPCS and PHPUnit runs were reviewed and confirmed by me in a local development environment.

[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]

This is consistent with the same which was added in 68c0f19 on the next_tag() method:

wordpress-develop/src/wp-includes/html-api/class-wp-html-tag-processor.php

Lines 895 to 899 in b84edad

	* @return bool Whether a tag was matched.
	*
	* @phpstan-impure
	*/
	public function next_tag( $query = null ): bool {