With this "fix" pseudo types will be considered as an object. That's wrong.

object(Symfony\Component\PropertyInfo\Type)#15949 (6) {  ["builtinType":"Symfony\Component\PropertyInfo\Type":private]=>  string(6)"object"  ["nullable":"Symfony\Component\PropertyInfo\Type":private]=>  bool(false)  ["class":"Symfony\Component\PropertyInfo\Type":private]=>  string(14)"numeric-string"  ["collection":"Symfony\Component\PropertyInfo\Type":private]=>  bool(false)  ["collectionKeyType":"Symfony\Component\PropertyInfo\Type":private]=>  array(0) {  }  ["collectionValueType":"Symfony\Component\PropertyInfo\Type":private]=>array(0) {  }}

pseudo types will be considered as an object

My fix doesn't change that. Before the fix it is an object too (but the$class property value has the first character trimmed, and this bug is the subject of my fix):

class Symfony\Component\PropertyInfo\Type#1168 (6) {    private$builtinType =>    string(6)"object"    private$nullable =>    bool(false)    private$class =>    string(13)"umeric-string"private$collection =>    bool(false)private$collectionKeyType =>    NULL    private$collectionValueType =>    NULL  }

Although it may beNULL insome cases. I think it depends on phpdocumentor version, but I'm not sure yet. Can you confirm?

By the way, if you expectednumeric-string pseudo-type to be mapped tostring built-in type, it will be done so in Symfony 6.1 thanks to#44451

Yes, currently it will be mapped to object (and the first character got removed).
But think about your fix. Is numeric-string really an object? No.

And in some software there will be done additional checks/procedures when it's an object. So this commit isn't really an fix.

I'm not trying here to fix the issue with psuedo-types being treated as object. It still is a big issue and I believe this behavior cannot be changed in older branches as this will be a BC break. It is undocumented feature - the documentation does not promise that the component handles pseudo-types and beforev6.1 it only handles a few of them. In my opinion we should implement it in major version and that's why I created#44455. But it's a hard problem to solve.

At the moment the least I can do without causing BC break is to merely fix the very issue with the first character being removed. If we fix it, I can work around the problem somehow (e.g. by checking ifclass_exists or by comparing it to predefined pseudo-types strings) in my project, what I can't do without the fix because the original phpdoc is in fact lost due to this bug.

Is numeric-string really an object? No.

Due tostring being a reserved keyword in PHP and- which is not allowed in a class name it never is. But consider this example:

class SomeClass{/**     * @var scalar     */public$scalarProperty;}class scalar {}

scalar is a pseudo-type handled by PHPStan. But if thescalar class is defined, it may as well be an object. Before the fix, extractor gives me an object withcalar className and I expectscalar - that my fix resolves.