<div dir="ltr">(doh, obviously that first "constexpr" shouldn't be there)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 5:22 PM Sam McCall <<a href="mailto:sammccall@google.com">sammccall@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This program creates an AST of depth 10000:<div><br></div><div>constexpr </div><div>template <class T, T...V> struct seq {<br></div><div>  constexpr bool zero() { return (true && ... && (V == 0)); };<br></div><div>};</div><div>constexpr unsigned N = 10000;</div><div>auto x = __make_integer_seq<seq, int, N>{};<br></div><div>static_assert(!x.zero(), "");<br></div><div><br></div><div>On my machine, clang-10 parses this successfully (slowly!) but crashes if I increase to 100000.</div><div>I suppose -ftemplate-depth doesn't apply as there's no actual recursion here (just fold-expressions), but I feel like some implementation limit *should* apply: clang relies heavily on being able to traverse the AST recursively, and will inevitably crash if the tree is too tall.</div><div><br></div><div>Should there be a limit here? It seems tempting to say one of:</div><div> -ftemplate-depth should constrain either the number of arguments a pack can represent</div><div> -ftemplate-depth should constrain the size of pack that can be unfolded</div><div> -some limit should constrain the overall AST height</div><div><br></div><div>---</div><div><br></div><div>The immediate problem we're dealing with is that <a href="https://reviews.llvm.org/D85621" target="_blank">https://reviews.llvm.org/D85621</a> increased the size of DynTypedNode from 32->56 and we're seeing clang-tidy crashes due to stack overflow in the recursive traversal MatchASTVisitor::memoizedMatchesAncestorOfRecursively.</div><div><br></div><div>However this is on a unit test very similar to the above (with N=2000) so before trying to squeeze stack usage I'd like to understand what we should be aiming to support.</div><div><br></div><div>(Tangentially related: Richard, if you think there are good ways to squeeze TemplateArgumentLoc, that'd be interesting to know. Currently it's by-value and holds TemplateArgument and TemplateArgumentLocInfo which are 24 bytes each)</div></div>
</blockquote></div>