fixed bugs that caused compiler to hang forever when there is %tcinline pragma #3272
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
(This pull request is a continuation of pull request #3257, since github doesn't allow me to re-open it)
close #2995
This pull request consists of two part:
%tcinline_fuelto avoid totality checker from infinitely inlining recursive function with%tcinlineand hang forever. The default value of%tcinline_fuelis1000.CallGraph.idrthat caused compiler to hang forever even when%tcinline_fuelis set.The second part is somehow rely on the first part, so it can't be divided into two pull requests .
Description of the first part
As issue #2995 mentioned, this code will cause totality checker to hang.
By adding new pragma
%tcinline_fuel, this problem is solved. A new testtotal027is added to test this new pragma.Description of the second part
And also as issue #2995 mentioned, this code also hangs compilation.
But surprisingly, after adding new pragma
%tcinline_fuel, it still hangs compilation. It was caused by a bug inCallGraph.idr.The lambda function with pattern matching
\(x::xs) => ...is actually encoded in such way(fis a fresh variable):In CallGraph.idr, such
fis called a case function, and they are treated specially: each timefindSCallmeets a case function, it will jump to the definition of the case function, and it won't be treated as regular function call.After tcinlining,
fbecomes a recursive definition:In such way,
findSCallinCallGraph.idrwill loop forever here, since it corresponds to a program of infinite length:The fix in CallGraph.idr introduce a new parameter
cbs. Each timefindSCallenters a case function, it appends the function name tocbs. If it's already there,findSCallthen will treat it as a regular function call.