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
Is there a design reason that LoopSpawning, at several points, checks the return value of verifyFunction() and, if the verification fails, it merely returns false indicating it did not transform anything, despite the fact that, at those locations in the code, some transformations have indeed been attempted? Was there some point during development where letting bad transformed code continue through the compilation pipeline made sense? I have sometimes locally changed the verifyFunction() checks into asserts which was useful when I was debugging an issue,
The text was updated successfully, but these errors were encountered:
Is there a design reason that
LoopSpawning
, at several points, checks the return value ofverifyFunction()
and, if the verification fails, it merely returnsfalse
indicating it did not transform anything, despite the fact that, at those locations in the code, some transformations have indeed been attempted? Was there some point during development where letting bad transformed code continue through the compilation pipeline made sense? I have sometimes locally changed theverifyFunction()
checks into asserts which was useful when I was debugging an issue,The text was updated successfully, but these errors were encountered: