-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[PropertyInfo] Add support for phpDocumentor and PHPStan pseudo-types #44451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PropertyInfo] Add support for phpDocumentor and PHPStan pseudo-types #44451
Conversation
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
The PhpstanExtractor should support the phpstan pseudo-types |
I agree and it would be great if PropertyInfo supported all of PHPStan's types, but it is a very complex system with integer ranges, generics, complex array shapes, literals and constants etc. so it will need a lot of work to support them all. We can work on it in future PRs but I think it is too much for just one PR. All pseudo-types that are currently supported by phpDocumentor are also valid PHPStan pseudo-types so it didn't make sense to me not to add them to |
@EmilMassey supporting the full type system might be too complex indeed. But you could at least support the full list of pseudo-types (i.e. also |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a future iteration, it could be useful to give access to the pseudo type to the end use.
For instance, this could help generating a more precise JSON Schema in API Platform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The low-deps test failure looks related. Can you have a look?
Fixed, thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding this feature to PhpStanExtractor !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure: do we need to merge this as a bugfix on 5.4 since we changed the default extractor, and not supporting theses types might break existing apps?
In a future iteration, it could be useful to give access to the pseudo type to the end use.
true, PR welcome or issue at least :)
src/Symfony/Component/PropertyInfo/Tests/Extractor/PhpDocExtractorTest.php
Show resolved
Hide resolved
src/Symfony/Component/PropertyInfo/Tests/Extractor/PhpDocExtractorTest.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/PropertyInfo/Tests/Extractor/PhpStanExtractorTest.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/PropertyInfo/Tests/Fixtures/PhpStanPseudoTypesDummy.php
Show resolved
Hide resolved
The change is too heavy for a bugfix, imho.
The PHPDoc extractor on 5.3 did not understand most pseudo-types either. See #44578. |
Thank you @EmilMassey. |
… (EmilMassey) This PR was squashed before being merged into the 4.4 branch. Discussion ---------- [PropertyInfo] strip only leading `\` when unknown docType | Q | A | ------------- | --- | Branch? | 4.4, 5.4, 6.0 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #44455 (partially) | License | MIT | Doc PR | - Fixes issue in `PhpDocExtractor` when dealing with some pseudo-types (`non-empty-string`, `positive-int`, etc.): ```php class TestClass { /** @var non-empty-string */ public $foo; /** @var positive-int */ public $bar; } $extractor = new \Symfony\Component\PropertyInfo\Extractor\PhpDocExtractor(); $fooType = $extractor->getTypes(TestClass::class, 'foo'); // $builtinType: object, $class: on-empty-string (first character trimmed) $barType = $extractor->getTypes(TestClass::class, 'bar'); // $builtinType: object, $class: ositive-int (first character trimmed) ``` The bug exists in 4.4, 5.4 and 6.0. It may exist in 6.1 as the invalid line is still there, but due to changes made in #44451, above snippet will no longer produce the bug. I was not able to reproduce the error in 6.1, but I suspect there may exist some pseudo-type that is still affected by the bug. I'm not sure if the test I wrote is OK, but it is the only way I could think of to validate my fix. In my opinion (see #44455), unknown pseudo-type should not be mapped to an object, so after the fix handling of pseudo-types is still broken but at least the results are consistent between `PhpStanExtractor` and `PhpDocExtractor`. But I agree with @derrabus (#44455 (comment)) that until there is no way to detect if we are dealing with a pseudo-type, assuming it is a reference to an object is the sanest thing to do. Commits ------- 723cd09 [PropertyInfo] strip only leading `\` when unknown docType
@nicolas-grekas if it possible to backport this changes to 5.4 branch? |
That's a new feature. 5.4 only accepts bug fixes now. |
@astronom If you need to support extracting these pseudotypes in v5.4, you can implement your own extractor. Note that this implementation requires |
More and more apps are using pseudo-types like
non-empty-string
,positive-int
which are understood by static analysis tools but are not a part of the language. This PR adds support for these types toPhpDocExtractor
andPhpStanExtractor
. Pseudo-type is mapped to built-in type(s) (e.g.non-empty-string
=>string
,positive-int
=>int
,number
=>int|float
).This PR adds support for all pseudo-types defined by the phpDocumentor (some of them like
list
ortrue
,false
are already supported) and PHPStan's basic types.