aaron.ballman added subscribers: thieta, tstellar, clang-vendors. aaron.ballman added a comment.
The changes generally seem reasonable to me, but I'm not 100% sure of the impacts of tying this to constexpr steps. That's a vague measure that was used mostly as an escape hatch for recursive constexpr evaluation. It seems reasonable to also tie it to array initialization (where each element of the array is one "step"), but it's not clear to me whether we're going to start rejecting code we used to accept or not. Because this is fixing a crash with code that's becoming more common (mostly through STL constexpr constructors), I see the appeal to getting this into Clang 17 and I think the current changes (tying to the max constexpr steps instead of constexpr steps remaining) are pretty conservative. However, because it's not a regression (this problem has existed for quite a while in Clang) and because we branch tomorrow, I think the most conservative approach would be to land this just after the Clang 17 branch. If post-commit testing doesn't bring up surprises before we start getting closer to putting out release candidates, we can cherry-pick this onto the release branch for early rc testing to widen the coverage and hopefully get the changes in 17. WDYT CC @tstellar @thieta Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155955/new/ https://reviews.llvm.org/D155955 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
