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_fuel
to avoid totality checker from infinitely inlining recursive function with%tcinline
and hang forever. The default value of%tcinline_fuel
is1000
.CallGraph.idr
that caused compiler to hang forever even when%tcinline_fuel
is 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 testtotal027
is 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(f
is a fresh variable):In CallGraph.idr, such
f
is called a case function, and they are treated specially: each timefindSCall
meets 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,
f
becomes a recursive definition:In such way,
findSCall
inCallGraph.idr
will loop forever here, since it corresponds to a program of infinite length:The fix in CallGraph.idr introduce a new parameter
cbs
. Each timefindSCall
enters a case function, it appends the function name tocbs
. If it's already there,findSCall
then will treat it as a regular function call.