You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As exposed in #492, TPP matchers all have asserts to make sure the number of ops is correct. This is a problem because:
It is poor software engineering practice to have to check the validity of functions. Checks should be in the functions.
If the number of arguments is wrong, the match should return false in the first place.
We don't want to "match-then-bail" on cases where the pattern does not match. We want to leave the code alone.
As standard compiler assumptions we must:
Assume the most strict matches possible, transform what we can.
Extend what strict means with time, to only the cases we know are safe and correct.
This leads to false negatives, as usual, but it gets rid of false positives. The former is a missed opportunity, the latter, can lead to broken code generation.
Any assert that validates the return of a matcher, yes. If the matcher returns true, then it's a match and we shouldn't have to second-guess. If we have an assert, we should move it inside the matcher and return false instead.
As exposed in #492, TPP matchers all have asserts to make sure the number of ops is correct. This is a problem because:
As standard compiler assumptions we must:
This leads to false negatives, as usual, but it gets rid of false positives. The former is a missed opportunity, the latter, can lead to broken code generation.
@adam-smnk @chelini
PS: We need to search for that pattern elsewhere and fix when it breaks the same assumption as this issue.
The text was updated successfully, but these errors were encountered: