AaronBallman wrote: Personally, I am not in favor of increasing the step limit without more compelling evidence for the need.
The purpose to having the step count in the first place is that reaching that limit is FAR more likely due to the user making a mistake and hitting infinite loops or quadratic loops they didn't intend on hitting than not. So having the step count somewhere reasonable means we break out of the compiler's process quicker so the user can repair their code and rerun the compiler. So I don't think we want to set the default limit based on "it's possible to hit the limit, look at this example which does" but instead base it on the (high end of) average workload. I can see a point to allowing for `=0` so a user can opt in without having to think too hard about what they're opting in to. But I don't think the limit actually needs to be raised without more evidence of the current limit being too low in practice. Pointing to libc++ tests isn't super compelling to me. (Btw, also worth keeping in mind that the implementation needs to test limits. So if we increase the limits in Clang, our constexpr stress tests will get slower for every precommit and postcommit CI pipeline as will any stress tests in libc++. So picking an arbitrarily high limit will have some negative impacts on our infrastructure as well. That's not a reason to *not* raise the limit, but it is something we need to keep in mind when picking new limits.) https://github.com/llvm/llvm-project/pull/143785 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
