Have you measured the compile-time overhead of this check? Also, the randomly strewn `-Wno-infinite-recursion` around the test suite is kind of worrying. Can those tests just be changed (in separate commits) to preserve what they are testing but not have spurious infinite recursion? I can't imagine that infinite recursion is somehow essential to what they are testing.
At a higher level, is this really needed as a compiler warning? I mean, it's nice and all to detect these things statically, but is this really something that needs to be happening on every build? Could we just do this in the static analyzer? In practice, I can't imagine any of these being hard to debug "while developing", since they will always result in a stack overflow the second they are called (and then you just look at the core file (or the debugger that your IDE attached) to see which function it was) (also, maybe Asan would intervene before the stack overflow and give you a nice pretty error report?). So essentially it seems like this is finding bugs in code that has no test coverage and has never been executed in practice; that kind of "cleaning out crusty unused parts of the codebase" seems like it would be better left to the static analyzer. Or do these kinds of infinite recursion things come up so often during development that having it be a warning is a big ti! me-saver for developers? http://llvm-reviews.chandlerc.com/D1864 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
