While technically correct, the change in 716a70de8524928036d5bc0d880d1117fa77de82 leads to false positive reports for code like this:

$abc = $request->query->get('abc');
Assert::notNull($abc);
expectString($abc); // 💥 Parameter #1 $str of function expectString expects string, bool|float|int|string given.

AFAIK Symfony never converts query string values from string to other types. So unless the $defaultValue argument is specified, InputBag::get() always returns string|null. And if $defaultValue is specified, the return type should be string|T where T extends string|int|float|bool|null.

Hi people,

As SerializerInterface, DenormalizerInterface has the same trouble.

So I just copy the code and adapt it to work with DenormalizerInterface.

Symfony 6 removed the Session and FlashBagInterface services.

That means that the only way to get the FlashBag (to add flashes) it to use $request->getSession()->getFlashBag().

But the problem is, getFlashBag is not defined on the SessionInterface:

Call to an undefined method Symfony\Component\HttpFoundation\Session\SessionInterface::getFlashBag().

To make everyone's life easier, let's change the return type to Sesssion instead. This is what's returned in a default Symfony application.

I'm not entirely sure this is a phpstan related issue.

When I check for session, ie:

 if ($request->hasSession()) {
     $request->getSession()->set('key', 'value');
}

I got the folllowing phpstan error:

Call to method Symfony\Component\HttpFoundation\Request::hasSession() will always evaluate to true.

If I comment out the use of phpstan-symfony OR the phpstan-strict-rules plugin, the error disappears.

Maybe related to https://github.com/phpstan/phpstan-symfony/issues/56

Symfony version 5.0 Phpstan versions: phpstan/phpdoc-parser 0.4.4 phpstan/phpstan 0.12.26 phpstan/phpstan-deprecation-rules 0.12.4 phpstan/phpstan-doctrine 0.12.14 phpstan/phpstan-strict-rules 0.12.2 phpstan/phpstan-symfony 0.12.6

if (!$container->has('doctrine.orm.entity_manager')) {
    throw new \InvalidArgumentException('Configure your entity manager correctly');
}

In my bundle I have a check for has service the phpstan throw the following error: If condition is always true. or Negated boolean is always false. because I think the service exist in my current configured container file. But this check is needed as somebody which don't have the other library imported or configured it different.

I think has should always be possible to be true or false.

Fixes #226

~~It's simplest and optimistic implementation which does not support:~~

• ~~%env()% syntax~~
• ~~%app.class%_decorator mixed interpolation~~

Let me know if we can start with this or should we work on most advanced scenarios 🙂

When using the KernelTestCase and asking PhpStan to analyze a test, I have this error:

However, the static::$container that is in the KernelTestCase is supposed to be an instance of the TestContainer but is typed as ContainerInterface because it might happen that the test.container service can be absent from the container, therefore making static::$container be the full container (as of KernelTestCase here )

Here is the code that triggers the error: Pierstoval/AgateApps/.../RedeemerTest.php#L61-L79

If the test.container service exists in the container AND for this specific case, I think there shouldn't be any error.

Hello,

Recently I saw on Twitter a Laravel user was complaining about type related stuff in Laravel console commands. And saw that @ondrejmirtes saying Artisan is just a wrapper around the Symfony Console. And suggested phpstan-symfony can be used to analyze the commands better.

So what I want to suggest is to extract all Symfony Console related rules and extension into a new package, so that it can also be used by Larastan. I'd like to avoid requiring the whole phpstan-symfony package there. I think that'd cause issues. Another option is to copy all the related code, but I don't like that solution.

What are your thoughts?

Hi @VincentLanglet, I had to change the stubs you contributed because of generic covariance error (https://github.com/phpstan/phpstan-symfony/commit/41fff98845bb8c4c0dc6c56f82b75358e57ccef9). Can you please test phpstan/phpstan-symfony:dev-master to see if it works as expected in real-world projects? Thank you.

Currently, its return type is a FormErrorIterator with inside Symfony\Component\Form\FormError|Symfony\Component\Form\FormErrorIterator

The phpdoc is

/**
     * Returns the errors of this form.
     *
     * @param bool $deep    Whether to include errors of child forms as well
     * @param bool $flatten Whether to flatten the list of errors in case
     *                      $deep is set to true
     *
     * @return FormErrorIterator An iterator over the {@link FormError}
     *                           instances that where added to this form
     */
    public function getErrors(bool $deep = false, bool $flatten = true);

So I would say it's always an iterator on Symfony\Component\Form\FormError, except if the parameter true, false are provided.

First I want to thank you for this great piece of software it make our live a lot easier and avoids a lot of bugs!

In the new update there was added that phpstan knows about the return type of getParameter. Parameter can be different between environments, so I think they should not be seen as constant values.

The following code in our case:

        if (SuluKernel::CONTEXT_WEBSITE === $container->getParameter('sulu.context')) {

Does produce now:

 ------ ------------------------------------------------------------------------------------------
  Line   src/Sulu/Bundle/WebsiteBundle/DependencyInjection/Compiler/RouteProviderCompilerPass.php
 ------ ------------------------------------------------------------------------------------------
  27     Strict comparison using === between 'website' and 'admin' will always evaluate to false.
 ------ ------------------------------------------------------------------------------------------

Another way could be that we introduce a option like we constant_hassers, which we also used in our setup (see discussion here).

I have an issue with ServiceSubscriberTrait (https://symfony.com/doc/5.4/service_container/service_subscribers_locators.html#service-subscriber-trait) on symfony 5.4 and PHP 7.4. Error message is like Service "App\Service\MyService::router" is not registered in the container.

How to reproduce:

1. Install this extesion
2. Add config as described in https://github.com/phpstan/phpstan-symfony#configuration

// phpstan.neon
    symfony:
        containerXmlPath: var/cache/dev/App_KernelDevDebugContainer.xml

3. Create class MyService and copy code from symfony docs.

// src/Service/MyService.php
<?php

declare(strict_types=1);

namespace App\Service;

use Psr\Log\LoggerInterface;
use Symfony\Component\Routing\RouterInterface;
use Symfony\Contracts\Service\Attribute\SubscribedService;
use Symfony\Contracts\Service\ServiceSubscriberInterface;
use Symfony\Contracts\Service\ServiceSubscriberTrait;

class MyService implements ServiceSubscriberInterface
{
    use ServiceSubscriberTrait;

    public function doSomething()
    {
        // $this->router() ...
        // $this->logger() ...
    }

    #[SubscribedService]
    private function router(): RouterInterface
    {
        return $this->container->get(__METHOD__);
    }

    #[SubscribedService]
    private function logger(): LoggerInterface
    {
        return $this->container->get(__METHOD__);
    }
}

4. Run phpstan

The output will be:

 ------ ------------------------------------------------------------------
  Line   src/Service/MyService.php
 ------ ------------------------------------------------------------------
  17     Method App\Service\MyService::doSomething() has no return type
         specified.
  24     Method App\Service\MyService::router() is unused.
  26     Service "App\Service\MyService::router" is not registered in the
         container.
  30     Method App\Service\MyService::logger() is unused.
  32     Service "App\Service\MyService::logger" is not registered in the
         container.
 ------ ------------------------------------------------------------------

Hello,

I'm having issues with cross-usage of psalm and phpstan for form type classes extending AbstractType:

• on psalm (v5) side with psalm-plugin-symfony, it's considered generic, thus adding the annotation /** @extends AbstractType<mixed> */ (or similar ^^) is needed to avoid getting MissingTemplate errors
• on phpstan side with phpstan-symfony phpstan will complain that AbstractType is not generic

I'm a bit lost in this situation, as I guess suppressing psalm's MissingTemplate errors is not the good thing to do 😅

I have a simple compiler pass like below:

<?php
declare(strict_types=1);

namespace App\DependencyInjection\Compiler;

use Faker\Generator;
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Reference;

final class AddCustomFakerGeneratorProvidersPass implements CompilerPassInterface
{
    public const TAG = 'app.faker.generator_provider';

    public function process(ContainerBuilder $container): void
    {
        if (!$container->has(Generator::class)) {
            return;
        }

        $svc = $container->findDefinition(Generator::class);
        $taggedDeps = $container->findTaggedServiceIds(self::TAG);

        foreach ($taggedDeps as $id => $tags) {
            $svc->addMethodCall('addProvider', [new Reference($id)]);
        }
    }
}

PHPStan with Symfony extension reports that has() will always return true:

 ------ ----------------------------------------------------------------------- 
  Line   DependencyInjection/Compiler/AddCustomFakerGeneratorProvidersPass.php  
 ------ ----------------------------------------------------------------------- 
  17     Negated boolean expression is always true.                             
  21     Unreachable statement - code above always terminates.                  
 ------ ----------------------------------------------------------------------- 

This is taken straight from Symfony docs at https://symfony.com/doc/current/service_container/tags.html#create-a-compiler-pass and they even add a separate warning stating "// always first check if the primary service is defined". Thus, I think this is a bug in PHPStan Symfony extension.

Here's my full PHPStan config:

includes:
    - vendor/phpstan/phpstan-symfony/extension.neon
    - vendor/phpstan/phpstan-deprecation-rules/rules.neon
    - vendor/phpstan/phpstan-strict-rules/rules.neon

parameters:
    level: 7
    tmpDir: var/cache/_phpstan
    parallel:
        jobSize: 20
        maximumNumberOfProcesses: 16
        minimumNumberOfJobsPerProcess: 2
        processTimeout: 30.0

    symfony:
        containerXmlPath: var/cache/dev/App_KernelDevDebugContainer.xml

    excludePaths:
        - %rootDir%/../../../src/DataFixtures/*
        - %rootDir%/../../../src/Migrations/*

    universalObjectCratesClasses:
        - Faker\Generator

    ignoreErrors:
        - '#^Call to an undefined method Faker\\Generator::#'

    tipsOfTheDay: false
    polluteScopeWithLoopInitialAssignments: false
    polluteScopeWithAlwaysIterableForeach: false
    checkAlwaysTrueCheckTypeFunctionCall: true
    checkAlwaysTrueInstanceof: true
    checkAlwaysTrueStrictComparison: true
    checkExplicitMixedMissingReturn: true
    checkFunctionNameCase: true
    reportMaybesInMethodSignatures: true
    reportStaticMethodSignatures: true
    checkTooWideReturnTypesInProtectedAndPublicMethods: true
    treatPhpDocTypesAsCertain: false
    checkMissingIterableValueType: false # handled by PHPCs with more granularity

I'm using the phpstan-symfony extension in a library so I'm not able to register the standard console application loader (as you would in a regular project)

So I've added a fallback to the default helper set symfony will register during setup of the console application.

See: https://github.com/symfony/symfony/blob/ea9ed6c821f76dfc5cf0639ebd1a23db971dc6e4/src/Symfony/Component/Console/Application.php#L1096-L1107

Most of the getHelper cases can be handled by this default set. When someone has custom helpers they should use the consoleApplicationLoader option.

Symfony supports PHP format for configuration (it's even default one now), so it would be great if this plugin could help with verifying DI configs. Assume we have:

class Foo
{
    public function __construct(Bar $bar, Baz $baz)
    {
    }
}

return static function (ContainerConfigurator $containerConfigurator): void {
    $services = $containerConfigurator->services();

    $services->set(Foo::class)
        ->public()
        ->args([Bar::class]);
});

Plugin should warn that Baz $baz argument is missing in the Foo service definition.

Similarly it should support:

• factories like ->factory([service(FooFactory::class), 'create'])
  • if factory's service exists
  • if factory's class has such method
• fetching parameters (like ->args(['%foo%']))
• named args (like ->arg('$bar', service(Bar::class))
• expressions (using expr())

That would really help with keeping quality in DI definitions with PHP format 🙂

Currently there is no way to override dynamic service return types on the container that are specified in ServiceDynamicReturnTypeExtension.

This is useful to provide more specific information e.g. if the service implement a generic class there is currently no way to teach phpstan that a specific service is of a specific type.

I already build a custom DynamicMethodReturnTypeExtension that adds the generic types, but in the end phpstan makes a union for all types returned by any DynamicMethodReturnTypeExtension. This leads to the less specific type of the smyfony extension "winning" and in fact overriding my more specific type again.

I would like to the a feature where you can specify the phpstan type of a service, or at least mark a service to be ignored by the symfony phpstan extension, so you can write your custom DynamicMethodReturnTypeExtension for those services.

Happy to contribute such a feature, but I'm currently not sure how to best implement this. The only way I see now is adding a custom tag to the service definition and specifying the type there and that type will then take precedence over the class name of the service.