I mostly faced the need in such tags, when a same error appears in several subsequent lines. The $container->getParameter() returns mixed results, but the constructor of the Config class expects specific ones.

Example:

new Config(
    // @phpstan-ignore-next-line
    $container->getParameter('kernel.debug'),
    // @phpstan-ignore-next-line
    $container->hasParameter('kernel.cache_dir'),
    // @phpstan-ignore-next-line
    $container->hasParameter('kernel.another_param'),
    // @phpstan-ignore-next-line
    $container->hasParameter('kernel.other_param'),
);

This could be written like this:

new Config(
    // @phpstan-ignore-start
    $container->getParameter('kernel.debug'),
    $container->hasParameter('kernel.cache_dir'),
    $container->hasParameter('kernel.another_param'),
    $container->hasParameter('kernel.other_param'),
    // @phpstan-ignore-end
);

FYI you can write a dynamic return type extension that would resolve a correct type for getParameter().

That is just an example. This feature is really needed.

Hello, I’m sorry but I feel very close to closing this feature request. To me it looks like every comment here describes a use case that has a proper solution other than ignoring whole blocks of code.

I’m afraid that the ability to ignore whole codeblocks with start/end annotations would support laziness of developers to grasp for easy solutions instead of proper ones and would be detrimental to PHPStan’s mission.

Another use-case would be developing on different branches and having a Controller/Command/whatever for testing your code which is not and will not be added to git. So, after switching branches, phpstan will complain about hundreds of errors because of missing classes etc. And I cannot spot the one error I have made after switching the branch and adding 2 lines of code for a bugfix e.g.

FYI you can write a dynamic return type extension that would resolve a correct type for getParameter().

For people with a similar use case than mine, there at least is a workaround (maybe another missing feature for PHPStan):

Instead of using get_class for the match, I now use match ($someObject::class) which works for the match. PHPStan will then complain: Match expression does not handle remaining value: class-string, but then I can just disable the check for the match line and there won’t be any other errors (not sure why though. Is the type properly resolved afterwards? Or is the superior union type used? Anyway.).

So, in code:

public function doSomething(ClassA|ClassB|ClassC|ClassD $someObject) {
    /** @phpstan-ignore-next-line */
    $something = match ($someObject::class) {
        ClassA::class => $someObject->some,
        ClassB::class, ClassC::class => $someObject->thing,
        ClassD::class => $someObject->else
    };

    $this->doSomethingWithSomething($something);
}

The combination of changes gets rid of the errors. I still think PHPStan needs better type resolving inside a match. 😃

I have another example for a usecase.

public function doSomething(ClassA|ClassB|ClassC|ClassD $someObject) {
    $something = match (get_class($someObject)) {
        ClassA::class => $someObject->some,
        ClassB::class, ClassC::class => $someObject->thing,
        ClassD::class => $someObject->else
    };

    $this->doSomethingWithSomething($something);
}

Sadly PHPStan doesn’t resolve the class of the object properly here and reports that some, thing and else are undefined even though they are defined on the respective classes.

Here is the error message (where some is a public property on ClassA):

Access to an undefined property
Full\NameSpace\ClassA|Full\NameSpace\ClassB|Full\NameSpace\ClassC|Full\NameSpace\ClassD::$some

I guess the best solution for my specific problem would be if PHPStan could infer the proper type based on the get_class comparison. But as things are, there are a lot of errors in my case, one for every line in the match where I access some property that is be there based on the actual type. The actual code has some more lines, so I would end up exploding my function body by six or seven comments just to disable PHPStan on all the affected lines.

https://phpstan.org/r/06c565b1-e501-459f-b846-0f92dec38512

This is boring example code but highlights something that in example code works fine. Yet when you write real world code which is always more complex phpstan frequently has trouble parsing these scenarios. The result? PHPStan whinging at you that x() expects array string but you are giving it array<int, string> or something equally baffling.

Stan, I assure you I am giving you the right bloody data. I even have it constructed right above with a doc block @var… but no. Stan whinging away.

This is why having the ability to ignore an entire block is so useful. Because PHPStan is not infallible and there is several situations where ignoring one line or next line will not work.

So what do I end up doing? Sod it. array mixed or just ignore swaths of code just to get rid of one stan parsing issue.

@kocoten1992 It’s hard to tell without a code example.

You can take advantage of stub files https://phpstan.org/user-guide/stub-files to override wrong 3rd party PHPDocs and you can also take advantage of all the PHPDoc features https://phpstan.org/writing-php-code/phpdocs-basics and types https://phpstan.org/writing-php-code/phpdoc-types PHPStan offers.

Anyway, feel free to open a new discussion about your specific issues 😊