-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
typecheck dataproviders #70
Comments
Yeah, would be nice, but traditionally we're checking if the parameter type accepts the argument type, so extra Also, this is complicated by multiple |
If this issue is not addressed (because of complexity or whatever), I was wondering if the return type of functions using as data providers could be simply ignored ? Currently, all my data providers have |
It's not addressed because no one has implemented it yet. It should be quite easy to do it. When I want to ignore the missing typehints, I usually add a configuration that looks like this:
|
Lucky you to have a |
Is someone working on this? If not, I'd like to give it a try! I'd focus first on checking that the test methods accept the data returned by providers (so not reporting that |
stumbled over this also again. please feel free to work on it. I will try to support you as good as I can. feel free to ping me if you have questions. |
so my suggestion on this topic would be:
wdyt? |
Tes, that's generally what you need to do. Also you need to look into other ways that test methods and data providers can be marked. |
There is already a DataProviderHelper in that extension that finds the corresponding data providers (to check they are defined). This logic can probably be reused (extracting the parts that are not about implementing the existing rule) |
it would be great when phpstan could typecheck a dataprovider function against the type-signature of the methods which is using it.
see this code taken from composer/semver
the dataprovider will never provide a
null
value for$min
.The text was updated successfully, but these errors were encountered: