Introduce RuleErrorFilterExtension

[ruudk]

This allows for more flexibility in filtering errors.

Some use cases:

• Ignore missingType.iterableValue on controller actions: Rule: when the method is public and it has #[Route] attribute or the class has #[AsController] attribute.
• Ignore should return int but returns int|null on getId for entities. Rule: class needs to have #[Entity] attribute.
• Ignore never returns null so it can be removed from the return type Rule: method needs to have #[GraphQL\Field] attribute.

This idea came from phpstan/phpstan#11134

Note

@ondrejmirtes Before I continue with adding tests and improving things, I would first like to know if agree with this functionality.

[LoogleCZ]

Hi,

this is exactly what I'm looking for right now as I'm working on Magento 2 projects when I'm bit of forced into following error:

Method Foo\Bar\Plugin\SomeClass::aroundBuildOutputDataArray() has parameter $dataObjectType with no type specified.
         🪪  missingType.parameter

I do not want to ignore all missingType.parameter errors in Method Foo\Bar\Plugin\SomeClass as suggested in comment, but I'd appreciate a way I can determine when the error will be filtered out (In my case, it will be all plugin methods, so class namespace will contain Plugin and method name will start with around/before/after with first argument strongly typed to some existing class).

I'd use this proposed feature or I can use configuration with something like this:

parameters:
	ignoreErrors:
		-
			message: '#^Method [a-zA-Z0-9\\_]+\\Plugin\\[a-zA-Z0-9\\_]+\:\:(before|after|around)[a-zA-Z0-9_-]+\(\) has parameter \$[a-zA-Z0-9_-]* with no type specified#'
			identifier: missingType.parameter
			path: */Plugin/*

And for the requirement to have strongly typed first argument and ignore error based on that - I can then create custom rule to check this condition. Maybe you can do that too in your case.

[ruudk]

@LoogleCZ Yes, with this extension you would be able to filter errors based on their class, namespace, if they use an attribute, if this extend from some base class, etc... Curious what Ondrej thinks about it 😊

[ondrejmirtes]

Yeah, this would be a nice addition. But there's a lot of details that we need to get right (because ignoring errors is one of the most popular and most widely used PHPStan feature!).

Some notes I have after thinking about this:

1. I'd avoid "filter" in the name. This should be "IgnoreErrorsExtension".
2. We have to think about when it makes sense to apply it. There are different shortcomings to different places. For example, does an error first go through ignoreErrors (config) and only after that through the registered extensions?
3. Do we pass Error or RuleError to the extension? I'm leaning towards Error for many reasons. For example, it'd be great if errors, even when eventually filtered out, would still be part of the result cache. Changing an IgnoreErrorsExtension would mean we don't need to invalidate the result cache. Also, ErrorFormatter works with Error.
4. Don't forget to also apply IgnoreErrorsExtension to errors produced by CollectedDataNode rules (in AnalyserResultFinalizer).