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
Closed
Fix stub @param types not applied inside method bodies (regression since 2.1.38)#5008mglaman wants to merge 1 commit intophpstan:2.1.xfrom
mglaman wants to merge 1 commit intophpstan:2.1.xfrom
Conversation
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>
3 tasks
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? |
Contributor
Author
|
🫠 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. |
Contributor
Author
|
Closing, the problem is more so in my test I bet in phpstan-drupal with what it is analyzing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
NodeScopeResolver::getPhpDocs()to consultStubPhpDocProviderbefore falling back toFileTypeMapperwhen resolving parameter types inside method bodiesStubPhpDocProvideras a constructor parameter toNodeScopeResolverNodeScopeResolverconstructor call sites in test infrastructure to include the new parameterProblem
Since 2.1.38 (PR #4829 — "Rework phpDoc inheritance to resolve through reflection instead of re-walking the hierarchy"), stub
@paramtype 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@paramtype instead.Root cause: The removed
PhpDocBlock::docBlockToResolvedDocBlock()helper previously calledStubPhpDocProvider::findMethodPhpDoc()first and fell back toFileTypeMapperonly if no stub was found. The rewritten path ingetPhpDocs()only consultedFileTypeMapper, never checking stubs.Fixes phpstan/phpstan#14118
Test plan
StubMethodBodyTypesTestverifies stub@param callable-stringoverrides source@param stringinside the method body@return non-empty-string🤖 Generated with Claude Code