I'd like a completely different approach than this.

1. Data providers usually don't come with precise typehints. So instead of comparing the return type of a data provider against the test case method signature, I'd like to inspect return, yield, and yield from in data providers against the methods that expects them.
2. I don't want to reimplement checking types passed into methods. PHPStan itself already does this, and contains years of edge case fixes. But it's possible that the logic (https://github.com/phpstan/phpstan-src/blob/1.9.x/src/Rules/FunctionCallParametersCheck.php) isn't reusable the best way so maybe first we need to refactor it.

It may be important to note that @dataProvider can be used in combination with @depends, and it affects the tests signature, see documentation.

1. Data providers usually don't come with precise typehints. So instead of comparing the return type of a data provider against the test case method signature, I'd like to inspect return, yield, and yield from in data providers against the methods that expects them.

I agree. With more and more complex method types, sometimes even conditional, it makes sense to actually not have any return type above data provider methods and infer the type from what the tests that require them expect.

Well, I would say that if the data provider method defines its return type, it should be used by the check instead of inferring it (as other rules will validate that the returned values match this type). But inferring it automatically when the type is not defined (or is just iterable or array without specifying the iterable value type), inferring is a good idea.

Well, I would say that if the data provider method defines its return type, it should be used by the check instead of inferring it (as other rules will validate that the returned values match this type). But inferring it automatically when the type is not defined (or is just iterable or array without specifying the iterable value type), inferring is a good idea.

Infered/accepting type (defined by accepting test method) should be always used.

However, data provider type might be narrower, the infered/accepting type should be intersected with this type.

I will re-evaluate based on the given feedback and start a new PR if I have something to review