TResult is present but unused in AbstractQuery.stub

[arderyp]

PR coming...

[ondrejmirtes]

TResult is used although it's not obvious at first sight.

[ondrejmirtes]

See

phpstan-doctrine/src/Type/Doctrine/Query/QueryResultDynamicReturnTypeExtension.php

Line 86 in 31a924b

$queryType->getTemplateType(AbstractQuery::class, 'TResult'),

[arderyp]

it's not working for me, as discussed here: phpstan/phpstan#10906 (comment)

You've defined it at the top, but not used it in any doc blocks as actual returns

[ondrejmirtes]

Please show an example code that uses these methods and show what \PHPStan\dumpType() says about the result. For example getSingleResult doesn't need to be in the stub because it's handled by QueryResultDynamicReturnTypeExtension.

[arderyp]

Without the addition of these lines in my own stub file that overrides AbstractQuery.stub, as explained in the other issue, I get tons of false errors from my repository classes. I will try to give you more to work with when I get a minute. Is there any reason these doc returns are not used, not usable, or break things? This seems like the standard way generics are used elsewhere

[ondrejmirtes]

I get tons of false errors from my repository classes

I'm interested in the false errors. It's very likely there are different solutions needed to those errors.

[arderyp]

If I remove that stub file, I see 30 errors. One example:

 Line   src/Users/Repository/UsersRolesRepository.php                                                                                           
 ------ ---------------------------------------------------------------------------------------------------------------------------------------- 
  76     Method App\Users\Repository\UsersRolesRepository::findById() should return App\Users\Entity\UsersRoles|null but returns mixed.  
         🪪  return.type 

<?php

declare(strict_types=1);

namespace App\Users\Repository;

use App\Users\Entity\UsersRoles;
use Doctrine\ORM\EntityRepository;
use Doctrine\ORM\NonUniqueResultException;

/** @extends EntityRepository<UsersRoles> */
class UsersRolesRepository extends EntityRepository
{
    /**
     * Get fully hydrated UsersRoles entity by $id.
     * @throws NonUniqueResultException
     */
    public function findById(int $id): ?UsersRoles
    {
        return $this->getEntityManager()->createQueryBuilder()
            ->select('userRole', 'user', 'program', 'roleType')
            ->from(UsersRoles::class, 'userRole')
            ->leftJoin('userRole.programs', 'program')
            ->leftJoin('userRole.roleType', 'roleType')
            ->leftJoin('userRole.user', 'user')
            ->where('userRole = :id')
            ->setParameter('id', $id)
            ->getQuery()
            ->getOneOrNullResult();
    }
}

[ondrejmirtes]

Do you have objectManagerLoader configured? Check the README if in doubt.

[arderyp]

phpstan.neon

...

doctrine:
    objectManagerLoader: tests/Config/object-manager.php

...

object-manager.php

<?php

declare(strict_types=1);

use App\Kernel;
use App\ApiBundle\Utils\Type;
use Symfony\Component\Dotenv\Dotenv;

require __DIR__ . '/../../vendor/autoload.php';

(new Dotenv())->bootEnv(__DIR__ . '/../../.env');

$kernel = new Kernel(Type::str($_SERVER['APP_ENV']), (bool) $_SERVER['APP_DEBUG']);
$kernel->boot();
return $kernel->getContainer()->get('doctrine')->getManager();

symfony is latest 6.4

[ondrejmirtes]

Looks like we keep this mixed on purpose but I’m not expert on that

phpstan-doctrine/tests/Type/Doctrine/data/QueryResult/queryResult.php

Line 35 in 31a924b

* - Other methods have a default hydration mode of null and fallback on AbstractQuery::getHydrationMode(), so we can not assume the hydration mode and can not infer the return type

[arderyp]

Yes, I assumed there must be some reason for the mixed, which is why I left that alone. But I can't address the errors any other way without ignoring them, which is bad. And coincidentally, using the TResult in the exact way it was designed to use with generics does solve the problem, which is why I thought it was a bug, hence this issue and PR.

Does my PR break things?

If so I will just keep using my stub... though the duplicate class error I was reporting in the other issue is quite annoying. Again, if there was a command arg to warm cache, that would ease the headache

[ondrejmirtes]

1. Yes, it breaks things, you can see that from the failing tests
2. The trick with warming up the result cache to get rid of stub errors no longer works, it was fixed in latest PHPStan versions

[arderyp]

yikes, so then what to do here?

can I somehow ignore the vendor provided AbstractQuery.stub and then use my own instead?