Introduce IgnoreErrorExtension

[ruudk]

This allows for more flexibility in ignoring 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.
• Enforce missingCheckedExceptionInThrows partially, only for specific classes.

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).

[ruudk]

1. I'd avoid "filter" in the name. This should be "IgnoreErrorsExtension".

Sure

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?

If we would first want to process the ignoreErrors, then the current place where I call the extension does not make sense. How would we be able to get the Node at the ignoreErrors stage? I think that information is not part of the Error, right?

Is it even possible to put the Node in the Error, and restore that from the result cache?

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.

Sure, we can first call the RuleErrorTransformer and then pass the Error to the filter.

4. Don't forget to also apply IgnoreErrorsExtension to errors produced by CollectedDataNode rules (in AnalyserResultFinalizer).

Will take care of this later once we iron out 2 + 3 😉

[ondrejmirtes]

Yeah, if you need to access Node and Scope and not just stuff that's available on Error then my whole argument about result cache is moot.

[ondrejmirtes]

So to summarize:

1. Rename the extension so that it has "IgnoreError" in the name.
2. Call it after transforming from RuleError to Error.
3. Don't forget about calling in on CollectedDataNode rule errors.

Thank you!

[ruudk]

I pushed the requested changes, please have a look when you have time. When you think it looks OK, I will continue with adding tests and tweaking things.