Skip too complex guards #570
Conversation
Since too complex guards lead to skipping a function altogether now, this condition is redundant. Dropping it allows exhaustiveness checking to benefit from the simple refinements from guards that are supported.
There was a problem hiding this comment.
Hi again! I am also for lowering the number of false positives in cases our code is not smart enough yet. To be honest, I am not really sure of the scope/implications of the changes in this PR though. Do I understand it correctly that all functions that contain any guard other than a single is_TYPE/1 (such as is_integer/1) guard are now skipped (as refine_vars_by_mismatching_clause/3 throws the {skip, too_complex_guards} tuple?
test/known_problems/should_fail/type_refinement_should_fail.erl
Outdated
Show resolved
Hide resolved
test/known_problems/should_fail/type_refinement_should_fail.erl
Outdated
Show resolved
Hide resolved
Yes. I don't really see a better way to make the usability reasonable and at the same time not spend significant time on code which would just override the argument types to Proper tackling of complex guards requires two things: precise inference of types based on all operators (e.g. binary |
This PR skips processing functions which use complex guards in order to make Gradualizer more convenient for everyday use, based on the fact that such complex guards aren't handled properly yet. It's important to underline that this PR doesn't lead to fewer or inferior warnings, since the warnings that are skipped could only be false positives anyway, due to incorrect/missing parameter refinement.
This enables Gradualizer users to more conveniently use the tool on "random", i.e. Gradualizer-unaware, projects, thanks to fewer false positives being raised. The PR also contains examples of refactoring (some) unhandled Erlang constructs into equivalent ones that are already handled completely by the tool.
Gradualizer developers can see which Erlang constructs and what guards would be worth handling next. We can also see that with this change some assertions can be dropped from Gradualizer code, yet maintaining that the tool can self-check.