Conversation
|
In NodeScopeResolver there are places that are interested in Also - require your version of phpdoc-parser with the support added in composer.json, so that the pipeline can actually get green. Also, you have to guard any call to new method on PhpDocNode with |
|
thanks for the tips. I tried testing the PR with the following code <?php
use function PHPStan\Testing\assertType;
class X {
/**
* @param-out string $s
*/
function addFoo(?string &$s): void
{
if ($s === null) {
$s = "hello";
}
$s .= "foo";
}
}
function foo1(?string $s) {
assertType('string|null', $s);
$x = new X();
$x->addFoo($s);
assertType('string', $s);
}but I currently struggle with php-doc resolving. 2 problems arise:
|
|
I should write comments about my problems more often... sorry/thanks for rubberducking.. found the reason for doc-block resolving problem because I had mixed up caller and callee side of things - 48a2cf8. I think the PR works now as expected for basic method examples. open todo is for regular functions. I would implement a |
ba182dd to
53c3b12
Compare
|
phpstan-src/src/Analyser/NodeScopeResolver.php Lines 531 to 533 in f097ca9 |
e274a59 to
09342ee
Compare
2c3136e to
2df5ad2
Compare
|
You updated a lot irrelevant deps. You need to run just |
f43fc38 to
a7347f5
Compare
|
And now you get relevant build errors finally 😊 |
5823ae9 to
3cdc61b
Compare
|
I had a look into the psalm test-suite for some more advanced use-cases... I will push them as a followup after we got the basic support landed |
ondrejmirtes
left a comment
There was a problem hiding this comment.
Also please test a scenario where @param-out on a method is inherited from a parent:
- When the parameter names match.
- When the parameters are renamed (but it should still be applied based on parameter order).
- When the
@param-outis overriden for the same parameter in the child class.
src/Analyser/NodeScopeResolver.php
Outdated
There was a problem hiding this comment.
FunctionReflection|ExtendedMethodReflection should already have a method for @param-out tags. But to be honest, it should probably be an information for a specific parameter on ParameterReflectionWithPhpDocs to be really clean. Something like public function getOutType(): ?Type.
There was a problem hiding this comment.
You shouldn't definitely parse PHPDoc here again. That's a job for PhpClassReflectionExtension, BetterReflectionProvider::getCustomFunction() and NativeFunctionReflectionProvider.
test.php
Outdated
There was a problem hiding this comment.
This file shouldn't be commited.
|
fixed and rebased. thank you |
|
Thank you! |
|
btw: I opened a new issue on php-src, to add/discuss |
|
@staabm Could you describe and open another issue for flag constants added to the stubs too? Like all the valid constants for |
here we go: php/php-src#9900 |
requires phpstan/phpdoc-parser#150
refs phpstan/phpstan#6426 (comment)
closes phpstan/phpstan#7231
closes phpstan/phpstan#6871
closes phpstan/phpstan#6186
closes phpstan/phpstan#4372
see https://psalm.dev/docs/annotating_code/supported_annotations/#param-out-psalm-param-out
just put togehter the basic building blocks and tests:
I had the idea of adding param-out-type specification of the expressions right before the return-type of
FuntionLikes is handled - I have not yet an idea where this place is though and whether thats a good idea :)would be great to get a hint, where/how the actual param-out logic should be implemented.