Comment 7 for bug 515603

I do agree with you about the useful nature of the inlining of recursive functions. But the compiler could do a different number of the inlining passes, depending on the function's body size. So, it is quite hard (maybe I should say 'impossible' ?) to guess the last pass number - which will eventually crash the compiler.

In this situation, at least two solutions are possible:

1. Close this issue, and use *inline-expansion-limit* to deal with the complex cases.
2. Ban the recursive functions inlining into themselves, despite of any useful outcomes. What is interesting, one legacy comment in ir1util.lisp supports this too:

" ;; FIXME: If the objective is to stop the recursive
           ;; expansion of inline functions, wouldn't it be more
           ;; correct to look back through surrounding expansions
           ;; (which are, I think, stored in the *CURRENT-PATH*, and
           ;; possibly stored elsewhere too) and suppress expansion
           ;; and print this warning when the function being proposed
           ;; for inline expansion is found there? (I don't like the
           ;; arbitrary numerical limit in principle, and I think
           ;; it'll be a nuisance in practice if we ever want the
           ;; compiler to be able to use WITH-COMPILATION-UNIT on
           ;; arbitrarily huge blocks of code. -- WHN)
"

I would prefer the first variant - to close the issue, and to describe *inline-expansion-limit* somewhere in the manual, so the users will know about the problems with the recursive inlining. Previously, I was going to implement the second variant, but your decent examples about the inlining usefulness have changed my opinion. As usual, I will be glad to hear what other developers think about this.

Roman