Skip to content

Comments

Fix stub @param types not applied inside method bodies (regression since 2.1.38)#5008

Closed
mglaman wants to merge 1 commit intophpstan:2.1.xfrom
mglaman:fix/stub-param-types-in-method-bodies-2.1.x
Closed

Fix stub @param types not applied inside method bodies (regression since 2.1.38)#5008
mglaman wants to merge 1 commit intophpstan:2.1.xfrom
mglaman:fix/stub-param-types-in-method-bodies-2.1.x

Conversation

@mglaman
Copy link
Contributor

@mglaman mglaman commented Feb 20, 2026

Summary

  • Fixes NodeScopeResolver::getPhpDocs() to consult StubPhpDocProvider before falling back to FileTypeMapper when resolving parameter types inside method bodies
  • Adds StubPhpDocProvider as a constructor parameter to NodeScopeResolver
  • Updates all direct NodeScopeResolver constructor call sites in test infrastructure to include the new parameter

Problem

Since 2.1.38 (PR #4829 — "Rework phpDoc inheritance to resolve through reflection instead of re-walking the hierarchy"), stub @param type overrides were silently ignored inside method bodies. External callers of a stubbed method still saw the correct stub types, but the method's own body would use the source file's @param type instead.

Root cause: The removed PhpDocBlock::docBlockToResolvedDocBlock() helper previously called StubPhpDocProvider::findMethodPhpDoc() first and fell back to FileTypeMapper only if no stub was found. The rewritten path in getPhpDocs() only consulted FileTypeMapper, never checking stubs.

Fixes phpstan/phpstan#14118

Test plan

  • New StubMethodBodyTypesTest verifies stub @param callable-string overrides source @param string inside the method body
  • New test also confirms external callers still see stub @return non-empty-string
  • Full analyser + rules test suites pass (7752 tests, 0 failures)

🤖 Generated with Claude Code

NodeScopeResolver::getPhpDocs() was only consulting FileTypeMapper
(the source file's phpDoc) when resolving parameter types inside method
bodies, never checking StubPhpDocProvider for stub overrides.

This was a regression introduced in 2.1.38 by PR phpstan#4829, which rewrote
PhpDocInheritanceResolver::resolvePhpDocForMethod() and removed the
PhpDocBlock::docBlockToResolvedDocBlock() helper that previously called
StubPhpDocProvider::findMethodPhpDoc() first.

The fix mirrors the pre-regression behaviour: consult StubPhpDocProvider
before falling back to FileTypeMapper in the ClassMethod phpDoc
resolution path of getPhpDocs().

Fixes phpstan/phpstan#14118

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@mglaman mglaman changed the base branch from 1.11.x to 2.1.x February 20, 2026 15:08
@mglaman mglaman marked this pull request as draft February 20, 2026 15:12
@ondrejmirtes
Copy link
Member

Yeah, I know about this, I kind of didn't add support back for this after the refactoring on purpose, because it doesn't make sense to me.

Stub files are for overriding wrong 3rd party PHPDocs. Why do you have a wrong PHPDoc in your analysed code on purpose, and fixing it with a stub file?

@mglaman
Copy link
Contributor Author

mglaman commented Feb 20, 2026

🫠 because Drupal Core has been slow to adopt modern typing and proper phpdocs, relying on phpstan-drupal to fix them. I am 100% OK with this being the case, now. I just wasn't sure if it was an expected regression.

@mglaman
Copy link
Contributor Author

mglaman commented Feb 20, 2026

Closing, the problem is more so in my test I bet in phpstan-drupal with what it is analyzing.

@mglaman mglaman closed this Feb 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants